Bug#727708: loose ends for init system decision
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
>> 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").
I'm aware of only one case of that in the archive. It's certainly not
what we normally do.
> For me it's a different proposition to suppose that _every_ daemon
> should bring in these kind of dependencies.
It's only going to be *every* daemon if we select systemd as the default
init system, in which case we should be doing this in many daemons for
either socket activation or for readiness notification as part of a proper
systemd integration. If we do not select systemd as the default init
system, the only maintainers doing this will be those who want their
packages to work well with systemd or whose daemons are of particular
interest to people who want to run systemd as a non-default init system.
In which case, what's the harm? It's going to be very difficult to even
notice this dependency is there.
I think the position you're taking here is directly contrary to Debian's
position of deference and reasonable accomodation to things that people
want to work on.
> 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.
Adding [linux-any] to the Build-Depends line is not too fiddly, and if the
goal is to enable optional upstream support for systemd, that will be
sufficient. Besides, in general, it's up to the packager to decide what
is or is not too fiddly in how they want to package software.
Obviously, we should not add an unconditional build dependency for a
library that isn't available on some of our ports to software that can
work on those ports. But I think that's obvious. I'm happy to have us
say that explicitly if if helps.
>>> 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 you feel like Policy should give advice on this, you can bring it up in
the context of Policy. I don't think the exact mechanism of integration
is important enough for the TC to explicitly favor a particular mechanism,
and different upstreams may have different approaches. I'm not seeing the
important gain to Debian here in trying to standardize exactly how one
tells a daemon to use socket activation or readiness notification.
I also, for what it's worth, directly disagree with this advice with
respect to systemd because I think compatibility with how systemd is used
elsewhere is more important than any marginal gain from using a
configuration method that's not inherited by subprocesses by default,
particularly given that the standard systemd APIs include environment
sanitizing. But I also don't see any point in arguing about it here,
since I don't think this dispute is ripe (in the legal sense).
If you do bring it up in the context of Policy and we can't resolve the
debate there, it can get appealed to the TC and we can decide it here
separately, but I think this is all premature, given that the whole point
becomes basically moot if we don't pick systemd anyway.
If you're worried about programs configured with environment variables in
the archive, you've got quite a lot of work to do, starting with nearly
every Perl program in existence.
>> 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 ?
Sure. I think that's what's going to happen anyway. Again, it's not the
place of the TC (explicitly, per the constitution) to do design. Once we
decide on a direction, we should let the rest of the project work out the
details using our normal procedures. We have a fair bit of time left
before the jessie release, and I expect integration policy to be fairly
well-resolved by the end of February using our normal process. And even
if it's not, given that we need to support sysvinit for jessie anyway, I
expect most packages will not be in a rush to convert.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: