Marc Haber <mh+debian-de...@zugschlus.de> writes: > Russ Allbery <r...@debian.org> wrote:
>> Get rid of some of that complexity because it is pointless (you'll find >> that much of it is working around inadequacies in sysvinit). > Explain. For example, all the PID file handling is working around the inability to determine via better mechanisms whether or not the daemon is running. Much of the logic for changing users can be eliminated in favor of a declarative syntax. Various logic for determining whether the daemon is installed can be handled via a better syntax or by having the base unit file not be a configuration file (I prefer the upstart approach here, personally). Also, determining which flags to pass to the daemon from some other configuration file, which is a common use of /etc/default files, is a hack to work around the fact that an init script is not really user-editable. We therefore move the parts that we expect users to change into a separate, simpler configuration file to avoid making them brave the dangers of the init script and deal with lots of dpkg configuration file prompts when we fix bugs in the init script. But with a systemd or upstart configuration file, it becomes reasonable to have the user just edit that file directly to pass different parameters to the daemon, since the configuration file is already as simple, in many cases, as the /etc/default file was. >> Get rid of more of it by building a static configuration from the >> dynamic configuration when it changes, where appropriate. > So you are seriously suggesting to add an inotify trigger on the conf.d > directory instead of building the configuration right before it is > needed? Could you please find a better way of asking questions than putting a bunch of words in someone else's mouth that you clearly find absurd? It puts the conversation on a very uncomfortable footing and leaves me feeling like your goal is to discredit other participants in the conversation rather than understand what they were trying to say. I was thinking of cases where the /etc/default file or some similar configuration file is managed by debconf, such as with one of my packages (openafs-client). In those cases, systemd or upstart allows removing several levels of indirection and just generating the configuration file for the init system directly, instead of having an init script that loads configuration from another configuration file managed by debconf. In particular, both upstart and systemd configuration files can be fairly easily read by maintainer scripts, allowing us to preserve user settings that were made manually on the system, a requirement for configuration files. This is much harder to do with init scripts, which accounts for another chunk of the separation of init script and startup configuration. When the source of the configuration is debconf, we know exactly when it changes and don't need anything like inotify to know when to rebuild it. And if the output of that configuration file is an init system configuration that is also user-editable (which init scripts really aren't), that allows us to also support direct user edits of the underlying configuration without any additional complexity. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871u8oxjz6....@windlord.stanford.edu
