Bug#727708: loose ends for init system decision
Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > - avoid extra build-dependencies (eg on libsystemd)
> > - avoid extra runtime dependencies (eg on deb-systemd-helper)
>
> These requirements, on the other hand, I find completely baffling.
>
> This approach seems completely contrary to Debian best practices. Our
> standard practice with all packages is to fully enable all available
> features that make sense on Debian and don't pose some concrete risk.
The case in point is a little different. It's one thing to say that
mail daemons should come with ldap support enabled, or whatever (and
even then we sometimes have two versions e.g. "heavy" and "light").
For me it's a different proposition to suppose that _every_ daemon
should bring in these kind of dependencies. This is particularly the
case for build-dependencies on an avowedly and intentionally
non-portable program. Of course this can be made conditional, but
this is IMO too fiddly.
> > We should recommend:
> > - daemon authors and Debian maintainers should prefer command-line
> > options to environment variables
>
> I disagree with including this in a statement. I think it's outside the
> scope of what we were asked to resolve, and I don't think it's the place
> of the TC to offer this sort of general advise to upstreams.
It is very likely that Debian contributors will be implementing native
support for whatever readiness protocol, in the upstream parts of the
codebase. It is IMO appropriate for those contributors to get advice
on how to do this. Policy already gives advice on this kind of
thing. Given the context, and the fact that this advice is going to
be read by a lot of people as part of a big enhancement project, I
think it's appropriate for the TC to answer this question.
> If we're going to offer specific advice, we should limit it to the
> specific integrations that we're asked to consider. But I think we should
> be mindful of the restriction on the TC not doing design work and let
> Policy for packaging support of upstart and/or systemd be hashed out
> through the regular Policy process.
Are you proposing then that the TC should decide the default init
system, but asmk people NOT to start converting packages until the
policy questions are settled ?
Ian.
Reply to: