Re: Bug#762116: marked as done (general: Some packages depend on a particular init system)
-----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-----
Reply to: