Hello, the update from virtual/udev-208r2 to virtual/udev-208-r2 drops the abi useflags. Many packages of my system has been migratet from emul-linux* to use the abi_x86_32 useflag instead. Reproducible: Always Steps to Reproduce: 1. Migrate mesa 32 bit dependencies to use abi_x86_32 2. Try to install virtual/udev-215 3. Dependency confilct because of missing use flag Actual Results: So this breaks mesa (uninstalled mesa, so this looks now like) # emerge -uND world Calculating dependencies... done! emerge: there are no ebuilds built with USE flags to satisfy "virtual/udev[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]". !!! One of the following packages is required to complete your request: - media-libs/mesa-9999::x11 (Change USE: -abi_x86_32) (dependency required by "media-libs/mesa-9999::x11" [installed]) (dependency required by "x11-base/xorg-server-1.15.0-r1::own[-minimal]" [installed]) (dependency required by "@selected" [set]) (dependency required by "@world" [argument]) Expected Results: No dependency conflict because of a missing use flag in a virtual package
Created attachment 382070 [details] emerge --info emerge --info The correct sentence in the first post above: *the update from virtual/udev-208-r2 to virtual/udev-215 drops the abi useflags.
The overlay is out of date - chances are mesa isn't the only case. Compare with ebuilds in the main tree.
(In reply to Rafał Mużyło from comment #2) > The overlay is out of date - chances are mesa isn't the only case. > Compare with ebuilds in the main tree. so the real problem is, that mesa-9999 from the x11 overlay depends on virtual/udev instead of virtual/libudev ? (at least for gdm and dri3 useflag) Why does virtual/udev still exits? IMHO it should be masked and removed or it should have multilib compatibility? ( But I don't now the gentoo decisions according to virtual/udev changes... )
(In reply to Jan Buecken from comment #3) > Why does virtual/udev still exits? IMHO it should be masked and removed or > it should have multilib compatibility? ( But I don't now the gentoo > decisions according to virtual/udev changes... ) because it's still required (but it has nothing multilib specific left) virtual/udev -> (systemd-,)udevd daemon, udev.pc (uses for this virtual for udev.pc should be avoided, in favour of using udev.eclass to get udevdir) virtual/libudev:= -> libudev.so, libudev.pc, libudev headers virtual/libgudev:= -> like virtual/libudev, but for libugudev-1.0.so there is nothing multilib specific left in virtual/udev, but it's still required virtual for packages that need to define RDEPEND of virtual/udev if they need a running instance of udevd daemon, if in doubt, this dependency should be left out, and wait for bug report, libudev, libgudev-1.0 has many functions that work without the daemon this is a simple case of outdated overlay, see similar bug reports for gnome-overlay: https://bugs.gentoo.org/showdependencytree.cgi?id=506034&hide_resolved=1
Fixed and pushed. Next time, please either fix all the official overlays yourself or give people time to fix them for you before you remove something.
(In reply to Samuli Suominen from comment #4) > virtual/udev -> (systemd-,)udevd daemon, udev.pc (uses for this virtual for > udev.pc should be avoided, in favour of using udev.eclass to get udevdir) > virtual/libudev:= -> libudev.so, libudev.pc, libudev headers > virtual/libgudev:= -> like virtual/libudev, but for libugudev-1.0.so > > there is nothing multilib specific left in virtual/udev, but it's still > required virtual for packages that need to define RDEPEND of virtual/udev if > they need a running instance of udevd daemon, if in doubt, this dependency > should be left out, and wait for bug report, libudev, libgudev-1.0 has many > functions that work without the daemon Got it! Thanks for the description. I found https://bugs.gentoo.org/show_bug.cgi?id=518504 This is now fixed / a duplicate?
AND: In bug https://bugs.gentoo.org/show_bug.cgi?id=518504 the := operator is mentioned. I just checked out the x11 overlay and it is missing this operator...
(In reply to Jan Buecken from comment #7) > AND: > In bug > https://bugs.gentoo.org/show_bug.cgi?id=518504 > the := operator is mentioned. I just checked out the x11 overlay and it is > missing this operator... you are right. every EAPI=5 ebuild should get it with := and older ones preferably should be ported to EAPI=5 to support := only case where it's OK to leave := out, is that it's an old ebuild of the package, and latest has :=, so it doesn't make sense to port old ones anymore i'll change $summary and reopen the bug... so this doesn't get lost...
*** This bug has been marked as a duplicate of bug 518504 ***
