Created attachment 331900 [details] output of "cave info sys-fs/lvm2" (roughly equivalent to emerge --info) I'm using a mostly-stable system with some unstable packages (x86), including udev, and I ran into this while doing cave fix-linkage --library libudev.so.0 for udev-196-r1. lvm2-2.02.88 fails to compile with the following error when udev-196-r1 is installed: ---snip--- i686-pc-linux-gnu-gcc -O2 -march=native -mtune=native -fomit-frame-pointer -pipe -O2 -march=native -mtune=native -fomit-frame-pointer -pipe -fPIC -Wall -Wundef -Wshadow -Wcast-align -Wwrite-strings -Wmissing-prototypes -Wmissing-declaration s -Wnested-externs -Winline -Wmissing-noreturn -Wformat-security -Wredundant-dec ls -Wpointer-arith -O2 -O2 -march=native -mtune=native -fomit-frame-pointer -pip e -fPIC -Wall -Wundef -Wshadow -Wcast-align -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wmissing-noreturn -Wformat-se curity -Wredundant-decls -Wpointer-arith -O2 -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl ,--as-needed -Wl,--export-dynamic -L./libdm -L./lib -L./daemons/dmeventd -Wl,-O1 -Wl,--as-needed -Wl,--export-dynamic -L../libdm -L../lib -L../daemons/dmeventd -L../libdm \ -o dmsetup dmsetup.o -ldevmapper -ludev -lrt dmsetup.o: In function `main': dmsetup.c:(.text+0x6be1): undefined reference to `udev_get_dev_path' collect2: ld returned 1 exit status make[1]: Leaving directory `/var/tmp/paludis/sys-fs-lvm2-2.02.88/work/LVM2.2.02.88/tools'make[1]: *** [dmsetup] Error 1 make: *** [tools.device-mapper] Error 2 ---snip--- lvm2-2.02.88 compiles fine against udev-195 (and lower, I'd assume) lvm2-2.02.97-r1 compiles fine against udev-196-r1. Perhaps the lvm2-2.02.88 ebuild should be updated to depend on <=udev-195? --Arek75
Please attach the entire build log to this bug report.
Created attachment 331906 [details] build log Here's the build log for the failed build.
I resolved this by keywording: sys-fs/lvm2-2.20.97 ~amd64
Same problem for me. Kicked the can down the road like Xenith did by adding sys-fs/lvm2-2.20.97 ~amd64 to package.keywords
Adding sys-fs/lvm2-2.02.97-r1 (where did you 2 get 2.20? ;-) ) to keywords is a viable workaround, but doesn't really fix the problem unless that version of lvm2 can be stabilized, and even then I'm not sure that this shouldn't be fixed in the relevant ebuilds anyway, since it has the potential to break systems when unstable udev is used with stable lvm2. --Arek
(In reply to comment #5) > Adding sys-fs/lvm2-2.02.97-r1 (where did you 2 get 2.20? ;-) ) to keywords > is a viable workaround, but doesn't really fix the problem unless that > version of lvm2 can be stabilized, and even then I'm not sure that this > shouldn't be fixed in the relevant ebuilds anyway, since it has the > potential to break systems when unstable udev is used with stable lvm2. > > --Arek @ James Potts - sys-fs/lvm2-02.97-r1 is correct. And I agree completely that this is not a 'fix'. It just gets me through my emerge -uND --with-bdeps=y @world.
Looks like this has already been fixed: $ grep virtual/udev lvm2-2.02.* lvm2-2.02.67-r2.ebuild: <virtual/udev-196" lvm2-2.02.73.ebuild: <virtual/udev-196" lvm2-2.02.73-r1.ebuild: <virtual/udev-196" lvm2-2.02.88.ebuild: <virtual/udev-196" 10 Dec 2012; Ian Stakenvicius <axs@gentoo.org> lvm2-2.02.67.ebuild, lvm2-2.02.67-r1.ebuild, lvm2-2.02.67-r2.ebuild, lvm2-2.02.70.ebuild, lvm2-2.02.70-r1.ebuild, lvm2-2.02.72.ebuild, lvm2-2.02.73.ebuild, lvm2-2.02.73-r1.ebuild, lvm2-2.02.74.ebuild, lvm2-2.02.83.ebuild, lvm2-2.02.84.ebuild, lvm2-2.02.85.ebuild, lvm2-2.02.88.ebuild: fixed the virtual dependency as virtual/udev-0 wasn't inclusive enough
Futhermore, 2.02.97-r1 is now stable for compability with current stable udev-197-r3
