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

Bug#727708: call for votes on default Linux init system for jessie

Ian Jackson wrote:
> Anthony Towns writes ("Bug#727708: call for votes on default Linux init system for jessie"):
> > So looking at the votes today, I would have said that both Ian and
> > Andi's original votes are against this (ranking the options which
> > allow specifying a dependency on a specific init below further
> > discussion), and probably Steve's does too, although I assume that's
> > more an objection against the wording.
> > 
> > At least, the impact seems like it is:
> > 
> >  - init systems can provide whatever extra APIs they like
> >  - other packages can only use extra APIs if they have a dependency on
> > the providing package
> >  - packages may not depend on specific init systems
> > 
> >  * therefore packages cannot use the extra APIs
> (In the L options:) Yes, packages which aren't part of the init system
> aren't allowed to depend on those extra APIs.
> But packages which _are_ part of the init system are so allowed.
> (Think, for example, management guis or addons for a particular init
> system.)  Answering "no" to the question Q2a above would have
> forbidden that.

That is a very interesting clarification, and not one that seems at all
obvious from the text of 'L'.  'L' talks about "Software outside of an init
system's implementation", which does not seem like it would extend to
"management guis or addons".

So, for instance, GNOME Logs, a new upstream project specifically
designed to browse the systemd journal, could by the clarification above
be considered part of the init system, and thus can depend on it?

If so, I would be very interested in further clarifications regarding
what it takes to be considered part of an init system.

- Josh Triplett

Reply to: