On a multilib amd64 system, sys-fs/udev installs with libexecdir=/lib64/udev instead of the proper /lib/udev. This causes problems later for systems without a lib->lib64 symlink, because other packages assume that udev is installed properly, so they can install their files to /lib/udev such that udev will find them. Upstream has stated that the proper directory is /lib/udev *even under multilib*, as there are no shared libraries installed in /lib/udev.
Installing to /lib64/udev is mainly to satisfy multilib-strict setting. On each proper system the udev files are reachable via /lib/udev I don't know if it is supported to have only /lib32 and /lib64 but no symlink /lib -> /lib64 The main problem is that there is no /libexec directory like it is under /usr
I do not have a /lib32 directory at all: my 32-bit libs are stored in the FHS-mandated /lib directory. This setup involves setting SYMLINK_LIB=no and LIBDIR_x86=lib in the profile (which will eventually become the default, as I understand it). On such a system, the udev files are *not* reachable as /lib/udev, because /lib cannot be a symlink.
(In reply to comment #2) > I do not have a /lib32 directory at all: my 32-bit libs are stored in the > FHS-mandated /lib directory. This setup involves setting SYMLINK_LIB=no and > LIBDIR_x86=lib in the profile (which will eventually become the default, as I > understand it). On such a system, the udev files are *not* reachable as > /lib/udev, because /lib cannot be a symlink. Good argument. I did not know such setup is specified. So, then we should change /$(get_libdir)/udev to plain /lib/udev I guess.
*** Bug 365157 has been marked as a duplicate of this bug. ***
Fixed in udev-168.
* ERROR: sys-fs/udev-168 failed: * multilib-strict check failed! * * Call stack: * misc-functions.sh, line 979: Called install_qa_check * misc-functions.sh, line 697: Called die * The specific snippet of code: * [[ ${abort} == yes ]] && die "multilib-strict check failed!" * * If you need support, post the output of 'emerge --info =sys-fs/udev-168', * the complete build log and the output of 'emerge -pqv =sys-fs/udev-168'. * The complete build log is located at '/var/lib/portage/logs/sys-fs:udev-168:20110430-160729.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-fs/udev-168/temp/environment'. * S: '/var/tmp/portage/sys-fs/udev-168/work/udev-168' ____________________________________________________________________________ # ls -lsd /lib /lib32 /lib64 4 drwxr-xr-x 7 root root 4096 Apr 30 01:09 /lib 4 drwxr-xr-x 2 root root 4096 Sep 24 2010 /lib32 12 drwxr-xr-x 15 root root 12288 May 1 00:06 /lib64 # emerge --info|egrep 'Port|FEA' FEATURES="assume-digests binpkg-logs buildpkg collision-protect distlocks fakeroot fixlafiles fixpackages metadata-transfer multilib-strict news parallel-fetch preserve-libs protect-owned sandbox severe sfperms strict suidctl unknown-features-warn unmerge-logs unmerge-orphans userfetch usersandbox usersync" Portage 2.2.0_alpha30 (hardened/linux/amd64/no-multilib, gcc-4.6.0, libc-0-r0, 2.6.38-hardened-r1 x86_64)
Created attachment 271641 [details] build log
Unfortunately, when you make this ebuild put things in /lib/udev, you somehow cause it to install the rcscripts in /lib/rcscripts instead of /$(get_libdir)/rcscripts; currently, the latter is the correct directory.
(In reply to comment #6) > * ERROR: sys-fs/udev-168 failed: > * multilib-strict check failed! This has been fixed in profiles by adding udev to the list of exempt directories.
(In reply to comment #8) > Unfortunately, when you make this ebuild put things in /lib/udev, you somehow > cause it to install the rcscripts in /lib/rcscripts instead of > /$(get_libdir)/rcscripts; currently, the latter is the correct directory. Fixed in udev-168-r1.
This change seems to break other things though. See bug 365679.
(In reply to comment #11) > This change seems to break other things though. See bug 365679. I see no connection of this /lib/udev directory change and the new warning message udev prints when not using /run-directory but /dev/.udev.
