[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain

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

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

Yet under this proposal, the package maintainers would be fully entitled
to do exactly the things which necessarily result in this problematic

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

Reply to: