Summary: | [x11-overlay] media-libs/mesa: virtual/libudev[${MULTILIB_USEDEP}] dependency should be virtual/libudev:=[${MULTILIB_USEDEP}] | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jan Buecken <jb.faq> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 506034 | ||
Attachments: | emerge --info |
Description
Jan Buecken
2014-08-02 11:09:45 UTC
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 *** |