Re: Bug#727708: init system discussion status
Dimitri John Ledkov wrote:
>On 4 January 2014 19:42, Tollef Fog Heen <tfheen@err.no> wrote:
>> ]] Dimitri John Ledkov
>>> Fedora/RPM based distributions are significantly different, thus it is
>>> inevitable that we'll have to maintain a fork of systemd for best
>>> integration into Debian. This does not seem evident from the current
>>> systemd maintainers, which file bugs to disable/remove/override debian
>>> functionality and components with inferior systemd counterparts.
>>
>> Can you provide bug numbers for those allegations, please?
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=716812
Already being discussed with upstream, which will hopefully lead to a
single unified implementation, or failing that two compatible
implementations. I'd chalk this up to two projects which didn't
previously know about each other discovering each other and learning
about new requirements.
> Rejections on mailinglists and else where to split:
> /lib/systemd/systemd-multi-seat-x
> /lib/systemd/systemd-timedated
> /lib/systemd/systemd-localed
> /lib/systemd/systemd-logind
> /lib/systemd/systemd-hostnamed
>
> from systemd package to individual packages binary packages, or at
> least together but separate from systemd-init.
Based on the most recent mailing list discussions, it sounds like the
concern there is not "whether to split" but "who will do the work of
maintaining the patches needed to make these run without systemd", since
there's no point in splitting them otherwise. There's also the question
of whether those patches are sufficiently invasive to warrant packaging
the above items as a separate source package, which would have the
advantage of not delaying the adoption of new upstream versions of
systemd.
More importantly, it sounds like this has simply been deferred until the
outcome of the TC decision.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719738 - udev "follow
> upstream" change, granted, steps have later been taken back to
> preserve backwards compat.
As has been explained *many* times elsewhere, there is no point at which
you can assume all hardware has been detected; the Linux kernel simply
doesn't work that way. All hardware is handled as though it has been
hotplugged, and userspace must deal with it showing up at any time.
udev-settle is a massive hack that introduces major delays at boot time,
and no package in Debian should depend on that hack; it makes about as
much sense as putting sleeps into init scripts to hack around races
rather than fixing them.
It sounds like there are any number of ways to fix LVM to properly
handle dynamic hardware detection. From what I can tell, the ideal
scenario would be to enable lvmetad; the bug report linked above
contains a workaround to be run when lvmetad is not enabled. The LVM
maintainer seems unwilling to incorporate either of those fixes, due to
dissatisfaction with the way dynamic hardware detection works. However,
hardware detection in Linux (and by extension in udev) will not go back
to being simplistic and broken simply by wishing it so.
In any case, I see no bug in systemd there, except perhaps the unused
default /tmp directory used by the generators, which being unused is a
rather minor bug. Regardless, the issue has already been raised to the
technical committee, and is likely deferred by the TC until after the
init system decision. Personally, based on the information documented
in the bug report, it sounds like the ideal solution would be to always
enable lvmetad and not support running without it, rather than
incorporating the generators at all. Is there some downside to lvmetad?
However, even if you are unwilling to accept the above explanation about
how modern Linux kernels and udev work, it seems quite disingenuous to
link to the above bug as an example of a problem with udev, rather than
as a debatable controversy. Your summary in particular seems biased and
misleading.
- Josh Triplett
Reply to: