Bug#727708: init system discussion status
On Fri, 2014-01-03 at 20:26 -0800, Nikolaus Rath wrote:
> Clint Adams <clint@debian.org> writes:
> > On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
> >> or alternatively
> >>
> >> 4. Packages may, however, depend on a specific init system (which may
> >> not be the default init) for features that are not related to daemon
> >> startup. Such packages will only be installable on systems running a
> >> non-default init, but are permitted in the archive.
> >
> > As loath as I am to participate in this discussion, I have to ask
> > if your intent is to suddenly outlaw all the packages which depend
> > on runit.
>
> Are you asking me personally? No, that's not my intent. I merely think
> that a CTTE solution should spell out precisely to what extent a package
> must be compatible with the default init (i.e., if it must be fully
> working with the default init, or if it only has to provide daemon
> startup/supervision/shutdown for the default init). This is why I
> explicitly listed two conflicting, alternative wordings.
There are two different kinds of dependencies: dependencies expressed in
package metadata, and functional dependencies (as in whether the package
does anything useful with another init). Your earlier wording sounds
like it was talking about the former ("installable") and Ian's proposal
definitely was (explicitly mentioning package fields), but the "fully
working" you use now sounds like it's about the latter.
As the systemd-ui example shows, there could be packages which in no way
can be reasonably expected to work with another init. So I think a
blanket ban on functional dependencies would be wrong (which you also
seem to be saying). I don't see such obvious problems with banning
package-level dependencies (requiring the packages to just fail at
runtime instead), and such dependencies could cause problems such a
unexpectedly switching init as a side effect of installing/upgrading an
"unrelated" package or forcing uninstall of packages if you even
temporarily try booting with another init.
Reply to: