Gentoo Archives: gentoo-dev

From: Mart Raudsepp <leio@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev
Date: Tue, 11 Aug 2020 08:13:46
Message-Id: 6d551b1198fcc390e741a5056d85f297f7efdb72.camel@gentoo.org
In Reply to: Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev by "Michał Górny"
1 Ühel kenal päeval, T, 11.08.2020 kell 07:44, kirjutas Michał Górny:
2 > > Examples?
3 >
4 > I suppose nobody remembers the time (the previous year) where eudev
5 > broke reverse dependencies because of wrong version number, and it
6 > took
7 > around 3 months to get a fix (read: changing the version number) into
8 > ~arch.
9
10 Having forgotten about that (even when being directly involved in it),
11 it doesn't look all that bad in this example on hindsight.
12
13 Upstream issue tracker got a notification of it (being unusable for
14 mutter) in https://github.com/gentoo/eudev/issues/173 on 2019-05-12.
15 It was fixed upstream eudev on 2019-05-19, and the fix was released
16 into eudev-3.2.8, released on 2019-05-20.
17
18 But Gentoo virtual/libudev-232 still claimed >=eudev-1.3 is fine for
19 it, while mutter had to depend on >=virtual/libudev-228.
20 So eudev-3.2.8 already available in main tree was fine for mutter, but
21 there was no virtual/libudev-228, which would ensure >=eudev-3.2.8 and
22 that eudev version wasn't stable. So a quick fix would have been to add
23 a virtual/libudev-228 too in ~arch, which would have given a way to
24 ensure 228 by eudev-3.2.8, but this seems to have been overlooked,
25 thinking that a new eudev release is needed. This was compounded by no
26 (rather) quick replies from eudev maintainers to advise what to do with
27 the virtual. Eventually eudev-3.2.9 ended up being what is required, as
28 it provides claimed compatibility with libudev-243, which is new enough
29 for virtual/libudev-232.
30 So after initial Gentoo problem report[1] on 2019-09-11, and the
31 virtual/libudev bug report[2] on 2019-10-12, it all got solved by
32 stabilization request[3] of eudev-3.2.9 (and virtual/libudev restoring
33 eudev as provider) on 2019-10-28 with main arches dealing with it the
34 same day. ~arch was fixed on 2019-10-26, 1.5 months after initial bug
35 report, which per the above actually turns out actually not been an
36 ~arch problem, but ~arch mutter mixed with stable eudev. Affected
37 mutter version was only stabilized in 2019-12-08.
38
39 So virtual/libudev dropping eudev as provider for this forced stable
40 tree to be fixed to be technically correct.
41 I think the main takeaway point is that on virtual/libudev version
42 bumps, the eudev claimed versions need to be checked as well, and the
43 matching >= dep for eudev figured out from the start. What each eudev
44 version claims as the libudev version can be seen in the UDEV_VERSION
45 variable set at top of configure.ac.
46
47 Personally I believe the first choice for virtual/udev should be
48 sys-fs/udev instead of sys-fs/eudev for our users, as it's more
49 maintained upstream, but don't have any personal stake in it as my udev
50 provider is systemd.
51
52 Various changes in udev upstream that wouldn't be in eudev (yet) would
53 be dealing with rule changes and bug fixes, which aren't relevant to
54 those people that aren't affected by these bugs, but very relevant if
55 you are affected by them.
56
57 I don't think it would be impossible to have musl-supporting out of the
58 box udev out of systemd tarball, if there was someone actually working
59 with upstream systemd on it in a constructive manner, effectively being
60 the musl support maintainer as part of upstream community.
61
62
63 Mart
64
65
66 References:
67 1. https://bugs.gentoo.org/694014
68 2. https://bugs.gentoo.org/697550
69 3. https://bugs.gentoo.org/698698

Attachments

File name MIME type
signature.asc application/pgp-signature