Ü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. Mart References: 1. https://bugs.gentoo.org/694014 2. https://bugs.gentoo.org/697550 3. https://bugs.gentoo.org/698698
signature.asc
Description: This is a digitally signed message part
