Ühel kenal päeval, T, 11.08.2020 kell 07:44, kirjutas Michał Górny:
> > Examples?
> I suppose nobody remembers the time (the previous year) where eudev
> broke reverse dependencies because of wrong version number, and it
> took
> around 3 months to get a fix (read: changing the version number) into
> ~arch.

Having forgotten about that (even when being directly involved in it),
it doesn't look all that bad in this example on hindsight.

Upstream issue tracker got a notification of it (being unusable for
mutter) in https://github.com/gentoo/eudev/issues/173 on 2019-05-12.
It was fixed upstream eudev on 2019-05-19, and the fix was released
into eudev-3.2.8, released on 2019-05-20.

But Gentoo virtual/libudev-232 still claimed >=eudev-1.3 is fine for
it, while mutter had to depend on >=virtual/libudev-228.
So eudev-3.2.8 already available in main tree was fine for mutter, but
there was no virtual/libudev-228, which would ensure >=eudev-3.2.8 and
that eudev version wasn't stable. So a quick fix would have been to add
a virtual/libudev-228 too in ~arch, which would have given a way to
ensure 228 by eudev-3.2.8, but this seems to have been overlooked,
thinking that a new eudev release is needed. This was compounded by no
(rather) quick replies from eudev maintainers to advise what to do with
the virtual. Eventually eudev-3.2.9 ended up being what is required, as
it provides claimed compatibility with libudev-243, which is new enough
for virtual/libudev-232.
So after initial Gentoo problem report[1] on 2019-09-11, and the
virtual/libudev bug report[2] on 2019-10-12, it all got solved by
stabilization request[3] of eudev-3.2.9 (and virtual/libudev restoring
eudev as provider) on 2019-10-28 with main arches dealing with it the
same day. ~arch was fixed on 2019-10-26, 1.5 months after initial bug
report, which per the above actually turns out actually not been an
~arch problem, but ~arch mutter mixed with stable eudev. Affected
mutter version was only stabilized in 2019-12-08.

So virtual/libudev dropping eudev as provider for this forced stable
tree to be fixed to be technically correct.
I think the main takeaway point is that on virtual/libudev version
bumps, the eudev claimed versions need to be checked as well, and the
matching >= dep for eudev figured out from the start. What each eudev
version claims as the libudev version can be seen in the UDEV_VERSION
variable set at top of configure.ac.

Personally I believe the first choice for virtual/udev should be
sys-fs/udev instead of sys-fs/eudev for our users, as it's more
maintained upstream, but don't have any personal stake in it as my udev
provider is systemd.

Various changes in udev upstream that wouldn't be in eudev (yet) would
be dealing with rule changes and bug fixes, which aren't relevant to
those people that aren't affected by these bugs, but very relevant if
you are affected by them.

I don't think it would be impossible to have musl-supporting out of the
box udev out of systemd tarball, if there was someone actually working
with upstream systemd on it in a constructive manner, effectively being
the musl support maintainer as part of upstream community.


1. https://bugs.gentoo.org/694014
2. https://bugs.gentoo.org/697550
3. https://bugs.gentoo.org/698698

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to