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 problem ... 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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140221134111.ga22...@riva.ucam.org
