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 |