On 10/17/2014 11:26 AM, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: Re-Proposal - preserve freedom of choice of
> init systems"):
>> The implication here appears to be troubling for any upstream who wants
>> to rely on specific features of a given initsystem.
>
> Yes, indeed.
>
>> 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.
>
> But runit is exactly the scaffolding needed to do that, and already
> exists! runit can coexist peacefully with sysvinit, systemd, upstart,
> or whatever. There is no problem depending on runit because runit
> doesn't demand being pid 1, so it is nonexclusive.
nevertheless, runit behaves differently when it is pid 1 than when it is
used in a subordinate role to another initsystem. If i'm upstream and
i'm building mechanisms that integrate with runit *as it behaves as pid
1*, the implication seems to be that my work would not be welcome in debian.
>> This isn't surprising or specific to init systems, of course -- it's how
>> free software works.
>
> The problem with init systems is that you can have only one.
>
> If people want to make Debian derivatives that work only with a
> particular init system, that's completely fine. The reverse - trying
> to put back support for sysvinit, if it gets taken out of Debian,
> would be very very difficult.
i don't think that anyone has tried to remove support for sysvinit for
debian -- i certainly hope the sysvinit maintainers are unlikely to
leave the project or orphan the package. There may be packages that
don't work as well or integrate as well in a sysvinit-based debian
installation as they do for other choices of pid 1. But that is also
true if runit is my pid 1 -- some packages won't integrate as well with
my system if i choose this config. That doesn't mean those packages are
RC-buggy, it means i need to submit servicedirs for them and hopefully
find ways for developers to adopt them. Or to provide system service
packages that are distinct from packages containing the tools entirely
[0], so that anyone who wants to support service initialization on an
arbitrary initsystem can do so independently.
That said, i don't think that "putting back support for sysvinit" for
any given package that is unable to currently maintain it would actually
be as difficult as you make it out to be.
> As the upstream for our ecosystem, we
> in Debian have a special responsibility to retain the flexibility our
> downstreams might want.
Yes, we do. But we also have a responsibility to package and distribute
modern, upstream-maintained versions of useful free software even if
those versions have dependencies that some people might not find
preferable. We also shouldn't restrain packagers from uploading
software just because they don't have service initialization mechanisms
for every pid 1 that can possibly be used in a debian system.
I like both postgresql and runit, and am really happy that both these
things are in debian. But postgresql isn't RC-buggy just because the
system service doesn't start automatically when i choose to use runit as
pid 1.
Regards,
--dkg
[0] https://www.debian-administration.org/users/dkg/weblog/53
signature.asc
Description: OpenPGP digital signature
