-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/18/2014 at 12:10 PM, Holger Levsen wrote:
> So file it there, or rather please don't. Better send patches. > Really. Upstream has decided to go this way / these ways, the best > way to persuede them into another direction also, is by providing > code. Filing bugs against the individual packages which depend indirectly on systemd would not be productive. The bug is not that these packages depend on functionality which they need; the bug is that functionality which they legitimately want to depend on is provided by an init system, rather than by something that can run independently of any init system, but is not something that must necessarily be provided by anything that qualifies as an init system. I agree that this is an upstream bug, but the upstream in question is not that of the individual packages which indirectly depend on systemd, but that of systemd itself - and the design choices which lead to this undesirable situation appear to be intentional decisions (one might even say "policy") on their part. Thus, filing bugs about this against systemd (either in Debian or upstream) seems unlikely to be productive either. As a decent coder who is not familiar with the functionality in question except from a layman's perspective, the best approach I've been able to think of to resolving the current instance of this problem would be to redesign systemd such that its cgroups management takes place in a separate process, which does not depend on having systemd be PID 1 (or ideally be present at all), and then have the PID-1 systemd depend on that external process for its cgroups management - and fall back to a reduced-functionality mode, with no cgroups handling, if that process is not available. Alternately, to avoid the need for such a reduced-functionality mode, it could also work to copy the cgroups-management code out of the PID-1 systemd into a standalone form (with any modifications necessary to let it work that way), and then make sure that any updates or other changes to either set of cgroups-management code get applied in both places. But that would be much harder to sustain, in terms of keeping their functionality parallel and equivalent. Either way, libpam-systemd would then not need to depend on systemd-sysv in order get the cgroups-management functionality it needs; it could instead depend directly on the standalone separate daemon, and so could anything else which needs similar functionality. That would seem to break the chain which is the primary means by which packages indirectly depend on systemd-sysv, as far as I'm aware. I strongly suspect, however, that even if patches implementing either of these were to be provided to systemd upstream they would be rejected out of hand. If there is reason to think that I'm wrong in that, I'd be glad to know about it. Unfortunately, I lack the emotional fortitude to try to brave that breach (if you'll excuse my mixing metaphors). > I'm closing this bug because this ain't a general bug in Debian. (At the least, it's much closer to such than the usual "support request with no substantial information to go on" bugs that are what usually tends to get filed against general. ^_^) > Some packages depend on Gnome too (or KDE or some obscure OCAML > library) and it's no secret mean conspirancy that they do so, but > rather relying on some feature somewhere. Aka: "business as > usual". An init system is fundamentally different from a library, both because it's a more low-level system component, and because while it's possible to have multiple libraries installed and running in parallel it is not possible to have more than one init system running at a time. The problem is not that a package depends on a feature that it needs. The problem is that that feature is implemented primarily - or even only - - in an init system, but is not implemented in other init systems. Since it is not practical to require all init systems (present and future) to implement certain functionality, beyond that which is essential to the nature of an init system, the only way to avoid this is to require that no init system implement any feature that something outside of the init system might legitimately want to depend on - unless that feature is also implemented equally in a standalone form. - -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJUHwiUAAoJEASpNY00KDJrYNYP/2WNlyc/Nbu/GP58cM+KKMFC EEtcMVYZgy3hW6Ur6d/FeUUYNYfYkjqNqVWzlccdVh/t8b0U+fqA94vJuVNUxSbZ GapIePhwuKACY2AmMzPxhOKnDV4WtLI+sVsKQrrCWsRXSqqmjx7nEAHDwEXO9o8l 6BvlgZrGOotNCcdhs82uTYffj3B0UKPTa7xput7pBKdngiDXEFnj/262RiV13YQs NXhgFpGO9mbQozg79qPo3EHC+fi7QUryuTLwuGt1B2yR0F0kJmP911FrRIjH3pYu V1IFJt7KDDkGSGbBUOOkT1rXL93U3U9RlJCZJlGO3lGOoWi678ABnNdRSUc0WvBd BN7O0czKdXIRUyneFI8D+RH8uy20NDEoR11qk8zjnUgPya+6G/af5Ls3HN31Va4Y NsAd4kX7wUL6KOSaAeN1BzVUfo9ZqEmbV57TOLBaKvpSuVQlhZoE2ZEWGF8pjyrs i8UNVCVsfKiMEWFZxXoKqtjEVHyIy+GbVTdpxEhxokJ0oiQG4MrwKWonML0Y5pFO QhhkZIS+J9Dac6BOv8al7RGV7zDwYaIRUeAn7wosbUJ/uW3aT7o10ll+3EPl/Prw JNpneu18mPeO1eKogp2LRZd20Fc6jRIOVY6QLjZwtRcbNPcf5kL8zt32l1YB/Qw8 9/DldXPCVo0E6bY6NAv4 =DRV8 -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/541f0894.8060...@fastmail.fm
