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

Re: Re-Proposal - preserve freedom of choice of init systems

On 10/17/2014 10:33 AM, Ian Jackson wrote:
> If the fix is not easy then we have three options: the release team
> mark it `jessie-ignore', the GNOME maintainers fix it, or GNOME is
> removed from jessie.

The implication here appears to be troubling for any upstream who wants
to rely on specific features of a given initsystem.

As a developer, i've built tools that were deliberately minimal
*because* i want those tools to rely on functionality provided by the
initsystem of my choice.

Concretely, i've built tools that work only when you have the runit
package installed and functional as the local init system.

The implication of this proposed GR seems to be that those tools would
be unfit for inclusion within debian unless someone erects all the
additional scaffolding that runit provides (process supervision,
pipelined logfiles with autorotation and log msgs just sent to stderr,
restart on abnormal termination, no need for daemonization, clean
process initialization, etc), but does so outside of runit.

I don't think this makes sense -- we should not be rejecting upstream
packages from debian just because they are designed to take advantage of
features of a given init system.

I'm not opposed to helping people work within the confines of whatever
init system they prefer -- one of the things i love about debian is that
i've been able to run machines with runit as pid 1 for many years now.
But i have always understood that if i'm not using the default
initsystem, and something breaks from that interaction, i probably need
to fix it myself (and to submit patches to upstream and/or the debian
package if i want it to work better for other people who also use runit
as pid 1).

This isn't surprising or specific to init systems, of course -- it's how
free software works.

It sounds like there are a lot of people who care about making sure
things work with sysvinit -- that's great, and i hope that energy will
result in more functional sysvinit-based installations.  I'm happy for
us to maintain a healthy diversity, and want to see that work happen.

But i don't think it is (or should be) an RC bug just because your
particular package doesn't support my particular initsystem.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: