Hi Steve, and thanks for your bugreport,

Le 24.02.2012 10:05, Steve Langasek a écrit :
> Please find attached a patch for lsb that adds a new helper function to
> /lib/lsb/init-functions to support maintainer scripts that should behave as
> no-ops because the package is upstart-aware and upstart is in use.

Okay.

> I'm proposing this change in support of bug #591791, a bug against
> debian-policy which aims to come up with coherent rules about the inclusion
> of native upstart jobs in Debian.  This is not a very high-level
> abstraction, it still requires the init script to work out the correct
> return value for each invocation.  That's about as high-level as most of
> the other lsb functions get anyway, but if you'd like something different
> I'm certainly open to discussing.

tl;dr: Is the "LSB support package" really the good place to support
multiple init systems in Debian ?

I'm mostly fine with the current patch; I just wonder if
/lib/lsb/init-functions is really the good file/package to have all
those Debian-specific initscript functions. As was highlighted by the
#596529 bug, /lib/lsb/init-functions already ships way more functions
that what the LSB mandates.

I wonder if moving the Debian-specific (non-LSB) functions to an
hypothetic /lib/debian/init-functions or alike wouldn't make things
cleaner, e.g. maintained in a Debian-specific package, such as
`base-files` or `debian-initsupport` or `whatever`. We could even
consider that debian-initsupport package as the starting support for all
the "let's support more than one init system" problem.

On the other hand, as I expressed in my #596529 wontfix, many packages
in Debian currently depend on functions implemented in
/lib/lsb/init-functions and breaking that would certainly break wide
parts of the archive and just continue to add more functions to
/lib/lsb/init-functions is the easy way forward.

What do you think ?

Cheers,

OdyX

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to