Bug#727708: init system coupling etc.
On Thu, Feb 20, 2014 at 05:20:22AM +0100, Tollef Fog Heen wrote:
> ]] Colin Watson
> > So, in my amendment, I intended this to be the "cooperating groups of
> > packages intended for use with specific init systems", which language I
> > think I borrowed from your proposal. If logind-208 Depends: systemd (or
> > indeed if it's part of systemd), then that's fine, as long as it doesn't
> > end up being required by something else that isn't so intimately related
> > to the init system; in other words, a dependency on systemd doesn't
> > become any less a dependency on systemd just because it happens to be
> > spelled "Depends: logind" and there's only one provider available.
> To be honest, I'm not sure why init systems are being singled out
> here. It's not really feasible to run both kdm and gdm at the same time,
> or run multiple window managers at the same time or a whole host of
> other software. Or would you be as strongly opposed to having a tool
> (say an accessibility tool) depend on GDM because it provided interfaces
> that KDM doesn't? (I'm not sure this is actually true, but I could
> easily see it being true.)
They're being singled out because this is actually something people have
been proposing to do, and other people have objected.
Regarding the hypothetical about display managers, I can *conceive* of
situations where this might be an issue. It's less clear than with init
systems, though, because desktop software tends to naturally go with a
display manager in ways that it doesn't so naturally go with a
particular init system: assuming that grandomaccessibilitytool has a
visible interface, it's probably themed the same way as GDM, most of its
users will probably be using GDM already (or maybe LightDM, I suppose),
and so on. It's technically possible but pretty unlikely that a KDE
tool will suddenly decide that it really needs GDM and thus conflict
with the rest of your KDE desktop, or in general that you'd end up
wanting to install multiple packages that require different display
managers, just because most people tend to stick within a cooperating
set of packages for their desktop environment.
> I also find it curious how A depending on interface B provided by
> packages C and D becomes RC buggy because D is unmaintained and gets
> removed from the archive. It's not how we usually treat bugs.
I don't view this ballot option as stating that a particular package
becomes RC-buggy. It's making a statement about how our software ought
to be structured, not specifically assigning problems to one end or
other of a dependency arc. I still hold out some hope that maintainers
will actually cooperate and talk to each other about this kind of
If part of an init system (whether packaged monolithically or as an
add-on) that's essential for the operation of other software in the
archive with that init system used to work but then ceases to be
maintained enough to be shippable, then that's a serious regression for
that init system and we would want to look at whether it's still viable
at all or perhaps whether the component in question can be resurrected.
It shouldn't be just a mindlessly static approach where package A
becomes RC-buggy and we don't think about the underlying reasons that
led up to it. I think that situation is quite different, though, from
the situation where package A introduces a new interface dependency in a
way that's known to have only limited support.
Colin Watson [email@example.com]