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