sys-fs/udev-9999 uses EAPI-5 but it doesn't declare an ABI sub-slot [1]. This can lead to problems such as #454184 [2], where a package depends on udev, but the package manager lacks the ABI information needed to rebuild any dependencies broken by an upgrade. Fixing this requires that udev declare ABI sub-slots and that the other package (e.g. mesa) use the `:=` slot operator when depending on udev. This bug is about adding the declaration to udev. systemd installs several libraries with independent soname versions: systemd $ grep -B2 version-info Makefile.am | grep 'LDFLAGS \|version-info' libsystemd_daemon_la_LDFLAGS = \ -version-info $(LIBSYSTEMD_DAEMON_CURRENT):$(LIBSYSTEMD_DAEMON_REVISION):$(LIBSYSTEMD_DAEMON_AGE) \ libudev_la_LDFLAGS = \ -version-info $(LIBUDEV_CURRENT):$(LIBUDEV_REVISION):$(LIBUDEV_AGE) \ libgudev_1_0_la_LDFLAGS = \ -version-info $(LIBGUDEV_CURRENT):$(LIBGUDEV_REVISION):$(LIBGUDEV_AGE) \ libsystemd_id128_la_LDFLAGS = \ -version-info $(LIBSYSTEMD_ID128_CURRENT):$(LIBSYSTEMD_ID128_REVISION):$(LIBSYSTEMD_ID128_AGE) \ libsystemd_journal_la_LDFLAGS = \ -version-info $(LIBSYSTEMD_JOURNAL_CURRENT):$(LIBSYSTEMD_JOURNAL_REVISION):$(LIBSYSTEMD_JOURNAL_AGE) \ libsystemd_login_la_LDFLAGS = \ -version-info $(LIBSYSTEMD_LOGIN_CURRENT):$(LIBSYSTEMD_LOGIN_REVISION):$(LIBSYSTEMD_LOGIN_AGE) \ This makes the sub-slotting awkward [3], but for udev alone it should be easy to update the slot to track `LIBUDEV_CURRENT`. The situation is complicated by the fact that virtual/udev already exists as a multiplexer between various udev implementations. I'm not familiar enough with udev (or its alternatives) to know how synchronized the development is, and I'm not familiar enough with sub-slots to understand if the existing virtual/udev can be used as the ABI virtual for libudev, or if a new virtual/udev-abi is needed. Anyhow, hopefully this bug helps focus discussion on ABI sub-slotting in the udev ecosystem. [1]: http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators [2]: https://bugs.gentoo.org/show_bug.cgi?id=454184#c18 [3]: http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators#Multiple_ABIs_for_X.Org Reproducible: Always
systemd commits bumping LIBUDEV_*: d3a8698 build-sys: prepare 201 LIBUDEV_CURRENT=4 -LIBUDEV_REVISION=1 +LIBUDEV_REVISION=2 LIBUDEV_AGE=3 9ca3c17 build-sys: prepare release 200 LIBUDEV_CURRENT=4 -LIBUDEV_REVISION=0 +LIBUDEV_REVISION=1 LIBUDEV_AGE=3 946f182 libudev: implement udev_device_set_attribute_value() -LIBUDEV_CURRENT=3 -LIBUDEV_REVISION=2 -LIBUDEV_AGE=2 +LIBUDEV_CURRENT=4 +LIBUDEV_REVISION=0 +LIBUDEV_AGE=3 …revision bumps… 2001208 libudev: import hwdb and export lookup interface -LIBUDEV_CURRENT=2 -LIBUDEV_REVISION=6 -LIBUDEV_AGE=1 +LIBUDEV_CURRENT=3 +LIBUDEV_REVISION=0 +LIBUDEV_AGE=2 dbf61af udev: export udev_device_new_from_device_id() -LIBUDEV_CURRENT=1 -LIBUDEV_REVISION=4 -LIBUDEV_AGE=0 +LIBUDEV_CURRENT=2 +LIBUDEV_REVISION=0 +LIBUDEV_AGE=1 …revision bumps… 20bbd54 udev: libudev - bump soname, remove deprecated functions, introduce symbol vers ions -LIBUDEV_CURRENT=13 -LIBUDEV_REVISION=3 -LIBUDEV_AGE=13 +LIBUDEV_CURRENT=1 +LIBUDEV_REVISION=0 +LIBUDEV_AGE=0 … I have no idea why 20bbd54 resets the libudev version from 13.3.13 to 1.0.0. Very strange. I also don't see any recent case where LIBUDEV_CURRENT was 0, so maybe Zero_Chaos was using another udev supplier when he had #454184. From [1], ABI incompatabilities (requiring sub-slot bumps) should happen when `current - age` increases (if we're only worried about package upgrades, and not package downgrades). Should we worry about automatic recompiles on package downgrades? For upgrades, udev sub-slot bumps and recompiles only had to happen after 20bbd54 (if systemd's versioning follows [1]), from 2012-05-15, which was released in v183. [1]: http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
For what it's worth, eudev matches systemd up to 2001208, after which commits dealing with LIBUDEV_* get pretty odd. There are no further bumps to any of the LIBUDEV_* variables.
udev-171 used libudev.so.0 and now it's libudev.so.1 with current stable udev-200 it doesn't make sense to introduce subslot operator before there is a new SONAME version bump to libudev.so.2 (or possible same with libgudev, current is libgudev-1.0.so.0) also it's not clear yet how this should be implemented with virtual/udev in place, as the subslot operator would go there or otherwise nothing would rebuild as nothing depends on sys-fs/udev directly i'm inclined to close any requests for subslot operators if there is no SONAME version bump, adding it now would only trigger needless rebuilds like shown in bug 454530, Comment 2 and bug 454530, Comment #6, bug 454530, Comment #7 if bugzilla still had the resolution 'LATER', i'd use it, but for now this is also INVALID
(In reply to comment #3) > udev-171 used libudev.so.0 and now it's libudev.so.1 with current stable > udev-200 > > it doesn't make sense to introduce subslot operator before there is a new > SONAME version bump to libudev.so.2 > (or possible same with libgudev, current is libgudev-1.0.so.0) > > also it's not clear yet how this should be implemented with virtual/udev in > place, as the subslot operator would go there or otherwise nothing would > rebuild > as nothing depends on sys-fs/udev directly > > i'm inclined to close any requests for subslot operators if there is no > SONAME version bump, adding it now would only trigger needless rebuilds like > shown in bug 454530, Comment 2 and bug 454530, Comment #6, bug 454530, > Comment #7 > > if bugzilla still had the resolution 'LATER', i'd use it, but for now this > is also INVALID I'd like to note that udev seems to have reasonably frequent updates and changes to which you could tack this change onto to avoid the so called "needless" rebuilding. If a user is updating anyway it wouldn't hurt to add in subslot support.... Please consider this, it would make a lot of things much better as you know numerous things link to libudev...
(In reply to comment #4) > I'd like to note that udev seems to have reasonably frequent updates and but libudev.so has been at .1 for a long time now, and libgudev-1.0.so has always been at .0 no soname bump in sight at git, so libraries are out of the equation here > changes to which you could tack this change onto to avoid the so called > "needless" rebuilding. we handle everything else differently, like hwdb update gets updated in both postinst of hwids and udev, no other use cases than the libraries available and those are already out as explained > If a user is updating anyway it wouldn't hurt to add in subslot support.... yes it does hurt, causing useless rebuilds as explained by Pacho and Zac at bug 454530 -9999.ebuild will become -203.ebuild with a change of patchset= line, since there is absolutely no need to add subslotting to the ebuild, we are not going to do that > Please consider this, it would make a lot of things much better as you know > numerous things link to libudev... so? no soname bump, no subslotting
