On 02/17/2016 11:16 AM, Michał Górny wrote: > On Wed, 17 Feb 2016 14:38:05 +0100 > Chí-Thanh Christopher Nguyễn <chith...@gentoo.org> wrote: > >> Michał Górny schrieb: >>>> With the exception that Lennart Poettering is the lead developer of >>>> systemd/udev, while such a thing cannot be said about you and eudev. >>> He's lead developer of *systemd*. udev is a split part of systemd >>> codebase which has specific maintainers. >> >> systemd and udev share the same codebase. You can no longer build udev >> without systemd. udev is only a sub-project of systemd now, hence the >> name "systemd-udevd". > > Of course, sure. But since you seem not to be able to understand > basics: this *does not* mean Lennart is the only person having > influence on how udev progresses. Sharing the same repository > and utility libraries is not the same as being the same thing. > > Much like the Council does not strictly force the development of eudev. >
According to _AxS_, there are very few differences between systemd-udev
and eudev at the present time:
16:14 <@_AxS_> At this point there really aren't much in terms of
differences -- most of the code is the same as upstream, but the file
structure is different and obviously the build system is proper and
standalone. There's the rule-generator patchset but otherwise
things are pretty well the same iirc.
16:14 <@_AxS_> We *did* have a bunch of other things in eudev that
improved matters for older kernels or just general code/memory
improvements, but those have since been integrated upstream iirc
16:15 <@ryao> _AxS_: I recall hearing that eudev regressed with respect
to 2.6.32. If the older versions were not good enough and I had time, I
would try fixing that.
16:16 <@ryao> _AxS_: It is interesting to hear that patches to support
older kernels are now being merged by them. Kay told me that such
patches would not be merged.
16:18 <@_AxS_> ryao: eudev-3.x doesn't support the older kernels, true.
However we determined that was ok because (1) the older kernels like
openvz have had the appropriate functionality backported into them, and
(2) we're keeping the older eudev versions around.
The main differences at this time seem to be the rule-generator patchset
for users who like that, a better build system (what IcedTea is to
OpenJDK) and a stricter process for getting newer code. Specifically,
instead of just doing a revision bump with the implicit assumption that
it was tested, every change is reviewed and committed to a repository
that is tagged independently of systemd-udev.
If there are regressions because of something upstream did, which has
occurred in the past, and they made it into eudev, there is someone who
accepted the commit that is responsible for it. They should not only
have caught it, but they also should have put a plan in place for
dealing with it like was done with the regressed kernel version support.
If they did not, then the eudev project can revise its QA strategies to
ensure that it does not happen again. That is something that can only be
rigorously done with a separate project that imports code from a vendor
like FreeBSD does, which is precisely what eudev is.
That is clearly better than what we have with sys-fs/udev. Given that
the two are almost identical with sys-fs/eudev being better suited for
systems where PID 1 is not systemd, there really is no point in having
sys-fs/udev be the first provider for virtual/udev. There is also no
point in having sys-fs/udev become a separate package from systemd,
unless we decide to break every component of systemd from the part meant
to be PID 1 too, but that is contrary to what systemd upstream recommends.
If making sys-fs/eudev the default virtual/udev provider turns out to be
a bad decision, we can always revisit it, but it seems better than the
status quo that we have now. Having less review of new code is bad and
having systemd-udev split from the systemd package on systems that use
systemd makes no sense. If we continue having the split, systemd would
depend on sys-fs/udev and consequently the systemd profiles with systemd
in @system would be unaffected by whatever the provider order happens to be.
signature.asc
Description: OpenPGP digital signature
