Re: brasero requires systemd-sysv
On 03/09/14 17:14, The Wanderer wrote:
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.
A reasonable position. There's some awkwardness in this particular case,
though...
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.
... because this change (from systemd-logind manipulating cgroups
itself, to systemd-logind sending cgroups manipulation requests to the
dbus interface that is provided on systemd-as-PID-1 systems by systemd's
PID 1) was done in response to the decision of the kernel's cgroup
subsystem maintainer, Tejun Heo, that the way cgroups hierarchies worked
was terrible and a single hierarchy single-writer model would be far
more sensible.
(AIUI, opinions differ *quite* widely on the correctness and/or sanity
of this decision by Tejun Heo. I have no particular opinion on it myself.)
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.
This is indeed the case.
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.
It seems to me that it's likely to be hard to maintain that kind of
discipline in respect of components you're only implementing at all
because you want to use their functionality in something else you
maintain. That's not to say it isn't worthwhile, but it may not always
be worthwhile *enough* from the perspective of the people doing the work.
Reply to: