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.
Description: OpenPGP digital signature