Re: brasero requires systemd-sysv
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 09/03/2014 at 11:41 AM, Bzzzz wrote:
> On Wed, 3 Sep 2014 11:12:24 -0400 (EDT) Rob Owens <rowens@ptd.net>
> wrote:
>
>> I'd also like to know if there are any features of brasero that
>> *really* require systemd to be used as the init system --
>> features that would not work with sysvinit. I'm hoping Michael
>> or some other developers can chime in on this one.
>
> This doesn't work like that; it is a _chain_ of dependencies.
Which is in fact part of the problem: it results in something which does
not have anything to do with a particular init system "depending on"
that init system.
Such indirect dependencies are one thing when it comes to libraries,
runtimes, and so forth, but very much another when it comes to such a
low-level system component as the init system. (The more so because the
libraries and runtimes and so forth don't tend to conflict with one
another and can be installed in parallel, whereas only one init system
can be running at a time.)
In this case, the dependency chain can be broken by the alternative
dependency 'libpam-systemd -> systemd-shim' (the latter of which is not
actually part of, and only indirectly related to, systemd), but that's a
workaround; the base problem still exists.
IMO, any functionality which anything not part of the init system might
legitimately want to depend on - such as the functionality needed by
libpam-systemd - should be implemented first, primarily, and indeed
probably *only* as something that is *not* part of the init system.
Indeed, my understanding is that the cgroups-management functionality
needed by libpam-systemd was initially implemented separately in logind
and in the 'PID 1' systemd (and possibly elsewhere), and then refactored
so as to have only one implementation - the one in PID 1. It was only
after that that someone else, not related (AFAIK) to the systemd
project, implemented a standalone version via systemd-shim and the
separate cgmanager project.
One of the problems is that the systemd project seems to default to
implementing potentially-independent things internally, instead of
implementing them standalone and then making systemd (or whatever it is
they wanted the new things for) depend on the standalone implementation.
This leads to there being only the systemd-internal implementation, in
at least some cases, and thus to the systemd lockin which is one of the
things people complain about.
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not to control them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJUBz5YAAoJEASpNY00KDJrOBMP+QGcSNJFojPTq6y+ScmxarbX
A+M5F/wx2YTOeiQVk0/E76adlru3X95VjouTrYNUtqvX+DEilvOUm6rnuBEkhCx5
YzFH9nQSWO8O8N+ud+E5HmjL0EHGNpOquHqGpuE3uxz4vNfLnOI6D8BbHfCC2xKq
fuOFAYeW0B72GRsAMDgs0ZdpJd090sU44aIHZQt6r/uV1JN5jXE1uDbazhZpdE1d
YUoRLJU3aOMluwA/tF0800XH4RcNoM+sXRAC+4vHDk4Ph3ZxoZtgcNxBWGpBY2BB
XNunpObLxr0i7qRA727u8W+vpGvbyB5EPPzskuHxqS9smpF6feGUjH+ubM71N+GM
nfTPcq3j+m4FfO/x3HNSnoszuy8VucgdqZOGCDAEvh3eV8Csgts9emgh0ogdLCG8
dQ0yz12PTYy0sjhMuT2DbBL63kuclZq5BsyxzT+jmeDdDLLpK4y0Pvj90nDosMUS
AZI6d0gYc16BUVbwvJ9BnudbmCy/01YFeG2DHUedxajWxvgxohiU9+hXsAHS5N3w
M0qO852ya+A4+URjqVLiETbhWS/KrCgR58JFAepIfah/KaiI57wxoD5Tl6Jij51G
U2jGeMz4Wi8DhervH3Xpqu7LGO301sKoYbjeQ6uuzwa9S2rH58OhBknbsY6wnyI2
JbQDhseT7yZbSUT7icto
=gQ3r
-----END PGP SIGNATURE-----
Reply to: