On 10/18/2014 at 06:21 AM, Luca Falavigna wrote: > Dear fellow Developers, > > I would like to propose the following amendment proposal, and I > hereby call for seconds. > > > > ** Begin Alternative Proposal ** > 2. Specific init systems as PID 1 > > Debian packages may require a specific init system to be executed as > PID 1 if their maintainers consider this a requisite for its proper > operation by clearly mark this in package descriptions and/or by > adding dependencies in order to enforce this; and no patches or other > derived works exist in order to support other init systems in such a > way to render software usable to the same extent. One potential problem which I see with this: Imagine a scenario in which this GR had not been raised, and jessie had been released with systemd as default init system, and so forth. Imagine that the maintainer of package foo decides, as they are entitled to do under this proposal, that 'foo requires upstart for proper operation' (choosing upstart just as an example here), and adds a dependency on a hypothetical set-upstart-as-PID-1 package. Imagine then that someone who is running happily with systemd as PID 1 decides to install package foo. This would cause their system to be switched from systemd as PID 1 to upstart as PID 1, comparably to what now happens when someone who is not running with systemd as PID 1 installs a package which depends on systemd-sysv. It seems unthinkable to me that this would not be considered a problem; as far as I can tell, the only reason that the dependency-based switch to systemd under the current arrangement is potentially not considered a problem is that systemd has been designated as the default init system for jessie, which would not be true of upstart in this hypothetical case. Yet under this proposal, the package maintainers would be fully entitled to do exactly the things which necessarily result in this problematic scenario. According to my best assessment at present, that type of scenario seems to be exactly (or at least a significant part of) what the original GR proposal is trying to prevent - in a broader form, which is not specific to any particular pair of init systems. This proposal would not prevent that scenario, and indeed would seem to enshrine it as something which is fully allowed. The only way I can see to avoid that scenario without a rule that no package may depend on a particular init system being PID 1 would be to add functionality to apt and/or dpkg to detect (probably at dependency-resolution time) when a package install triggered via a dependency will trigger a change of init system, and *reject* the install - requiring that the user / sysadmin specify the new-init-system package explicitly, rather than as a dependency, in order to trigger the actual init-system change. I don't know how difficult that would be to implement, but I imagine that it would be at least mildly controversial as well, although probably much less so than either systemd has been or this GR is proving to be. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature