Once in the ebuild itself on line 29 ... and in the package itself: ... When merging 'sys-fs/fuse-2.7.0::gentoo' at '/var/tmp/paludis/sys-fs/fuse-2.7.0/image' to VDB repository 'installed': ... When checking merge from '/var/tmp/paludis/sys-fs/fuse-2.7.0/image' to '/': ... When checking merge from '/var/tmp/paludis/sys-fs/fuse-2.7.0/image' to '/': ... When checking merge from '/var/tmp/paludis/sys-fs/fuse-2.7.0/image/usr' to '/usr': ... When handling dir '/var/tmp/paludis/sys-fs/fuse-2.7.0/image/usr/lib' to '/usr': ... Expected '/usr/lib' to be a directory but found a symlink to a directory
can people with 64 bit architectures please develop a fix?
works in portage
sorry, how about $(get_libdir) instead of /lib/ and inherit multilib ?
eh, kernel /lib64 != user /lib64 dont know what is right here .. thats why someone who uses this needs to fix it if he thinks it needs fixing - go ahead tiziano.
(In reply to comment #4) > eh, kernel /lib64 != user /lib64 > > dont know what is right here .. thats why someone who uses this needs to fix it > if he thinks it needs fixing - go ahead tiziano. > it would have to be broken for a fix to be considered. using tc_getlibdir is not correct for kernel modules(which I can only assume is what was trying to be done here, there was no information provided on the bug) If anything, the bug would be in paludis.
my modules are living in /lib64/modules/*, why isn't it correct to use /$(get_libdir)/modules then?
because the kernel hardcodes /lib /usr/src/linux/Makefile:MODLIB = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE) Your modules appear in /lib64 because /lib is a symlink to lib64
Even though the modules should be hardcoded (but you don't care because linux-mod will take care of installing them for you), note that the userspace stuff (libraries and apps) should install to /usr/$(get_libdir) comment #0 suggests that userspace stuff is going into /usr/lib so this still may be a valid bug
(In reply to comment #6) > my modules are living in /lib64/modules/*, why isn't it correct to use > /$(get_libdir)/modules then? > The kernel defines the modules directory as /lib/modules/`uname -r`/. It doesn't know about lib{32,64}. Installing anywhere else, while it might work currently, will break in the future when we decide to remove the lib->lib64 symlink and have lib{32,64,} as all directories.
(In reply to comment #8) > Even though the modules should be hardcoded (but you don't care because > linux-mod will take care of installing them for you), note that the userspace > stuff (libraries and apps) should install to /usr/$(get_libdir) > comment #0 suggests that userspace stuff is going into /usr/lib so this still > may be a valid bug > installed through portage, it installs all the userspace stuff in lib64. While I can't guess what paludis does, based on previous comments, I can only assume we're talking about kernel modules.
(In reply to comment #10) > based on previous comments, I can only assume > we're talking about kernel modules. I only mentioned userspace stuff because: (In reply to comment #0) > ... When checking merge from '/var/tmp/paludis/sys-fs/fuse-2.7.0/image/usr' > to '/usr': > ... When handling dir '/var/tmp/paludis/sys-fs/fuse-2.7.0/image/usr/lib' to > '/usr': > ... Expected '/usr/lib' to be a directory but found a symlink to a directory > kernel module installation definitely doesn't put stuff in /usr
(In reply to comment #11) > (In reply to comment #10) > > based on previous comments, I can only assume > > we're talking about kernel modules. > > I only mentioned userspace stuff because: > > (In reply to comment #0) > > ... When checking merge from '/var/tmp/paludis/sys-fs/fuse-2.7.0/image/usr' > > to '/usr': > > ... When handling dir '/var/tmp/paludis/sys-fs/fuse-2.7.0/image/usr/lib' to > > '/usr': > > ... Expected '/usr/lib' to be a directory but found a symlink to a directory > > > > kernel module installation definitely doesn't put stuff in /usr > point taken. However when using portage, all the userspace was installed to /usr/lib64, and all the other comments seem to be about kernel modules. dev-zero will have to determine if paludis is erroring on installing the kernel module to /lib(a paludis bug) or installing userspace to /usr/lib(behavior which doesn't happen in portage, so a paludis bug) The little snippet posted doesn't give me enough information to guess.
There is no error, just a warning. But my question in the end is: In the ebuild, there's this line: BUILD_PARAMS="majver=${KV_MAJOR}.${KV_MINORR fusemoduledir=${ROOT}/lib/modules/${KV_FULL/\ }/fs" and since /lib points to /lib64, lib should be replaced by $(get_libdir), or not? And furthermore, the package itself installs stuff to /usr/lib instead of /usr/lib64, which would definetely break when we remove the /usr/lib->/usr/lib64 symlink (if that ever happens). And should we fix that for the packages or just ignore it?
(In reply to comment #13) > There is no error, just a warning. > > But my question in the end is: In the ebuild, there's this line: > > BUILD_PARAMS="majver=${KV_MAJOR}.${KV_MINORR > fusemoduledir=${ROOT}/lib/modules/${KV_FULL/\ }/fs" > > and since /lib points to /lib64, lib should be replaced by $(get_libdir), or > not? No. You should hack the FUSE makefile not to install the module so that you dont have to pass fusemoduledir or care about it at all. You should then use linux_mod_src_install to install the module. That's unless fusemoduledir is used for something other than module installation (e.g. a hardcoded insmod path in the source code?). I haven't checked. > And furthermore, the package itself installs stuff to /usr/lib instead of > /usr/lib64, which would definetely break when we remove the > /usr/lib->/usr/lib64 symlink (if that ever happens). > And should we fix that for the packages or just ignore it? Sounds like a bug in the ebuild, it should use /usr/$(get_libdir) as I suggested above. (but some comments above suggest that portage installs to /usr/lib64 on appropriate systems so maybe this is a paludis bug)
Just to clarify: fuse does install to /usr/$(get_libdir), FEATURES=multilib-strict doesn't complain about anything - can't really say something about the module, because it's not built here, using the in-kernel one. So the original description is a paludis bug.
*** Bug 209676 has been marked as a duplicate of this bug. ***
