It prevents to have /usr on diffrent partition than / . Reproducible: Always
Created attachment 271689 [details, diff] proposal of patch I'm completly not familiar with autotools, i suppose this patch is very bad. But it works for me:)
Created attachment 271691 [details, diff] patch for ebuild This patch for ebuild fix: - DEPEND - checks for PREEMPT kernel - changes localization libspl and libzfs - unrecognized options: --with-prefix - removes unneeded files installed in /usr/src/zfs - removes .la and .a files
I've forgot about checking if zlib is present in kernel.
Can you fix autotools patch so it will use $(get_libdir) to define libs so it will be multilib friendly =) After this i'll add zfs to tree
I have no idea how to do it. Autotools is high level magic for me:) I've noticed another script should'nt be in /usr. While booting, udev calls zpool_id but calls it before /usr is mounted. Zpool_id shoud be in /sbin and udev rules should have corrected paths.
Created attachment 271979 [details] proposal of ebuild I've did it in diffrent way, i hope it will work correctly on multilib.
Created attachment 271981 [details, diff] change_location.patch Patch fixing udev rules and location of zpool_id
Can you update your proposal ebuild and add all missing files? and after testing i'll try to merge this upstream
Created attachment 273571 [details] proposal of ebuild Ebuild with support for bash-completion (taken from zfs-fuse).
Created attachment 273573 [details] zfs_completion.bash
Created attachment 273575 [details, diff] zfs-0.6.0-includedir.patch
Comment on attachment 273573 [details] zfs_completion.bash File for bash completion.
Created attachment 273579 [details] zfs.initd Init script taken from science overlay.
If i forgot about any file, it should ba taken from science overlay.
Its no longer in sci overlay
I am willing to move the libraries and executables in /usr to / to be consistent with what the lvm2 ebuild puts things and where the shared libraries upon which ZFS' shared libraries depend are placed. The correct way to control where libraries and excutables go is to set --exec-prefix, but the ZFS upstream code does not obey it for the shared libraries that it installs. That can be worked around by setting --libdir, but I cannot do that in the ebuild without either tripping the QA checks or making cross platform compatibility a nightmare. That makes part of the solution to this bug an upstream issue, which I plan to report. With that said, you can workaround this on your system by passing these flags to emerge manually: env EXTRA_ECONF="--exec-prefix= --libdir=/lib64" emerge -1v zfs spl It might be possible to make this semi-permanent by using an env file, although I did not test this: http://wiki.gentoo.org/wiki//etc/portage/env
Here is an update: 1. --exec-prefix= is now set by the ebuilds in-tree, so the binaries are installed in /sbin. 2. I have updated my genkernel patches to reflect the change in tree. 3. A fix for the libraries being installed in the wrong directories will come as soon as upstream acts. It will not require any further changes to genkernel or the ebuilds. I will close this bug when upstream resolves the corresponding bug that I filed with them: https://github.com/zfsonlinux/zfs/issues/559
I can see none libraries from /usr are used now: # ldd /sbin/zfs |grep usr # # ldd /sbin/mount.zfs |grep usr # Btw, is it good place to keep headers file in /usr/src/zfs-0.6.0-rc6/3.2.2-gentoo/ directory? Maybe /usr/include/zfs/ would be better place?
(In reply to comment #18) > I can see none libraries from /usr are used now: > # ldd /sbin/zfs |grep usr > # > # ldd /sbin/mount.zfs |grep usr > # I could have sworn that it was installing them in the wrong locations. In that case, this issue is resolved. (In reply to comment #18) > Btw, is it good place to keep headers file in > /usr/src/zfs-0.6.0-rc6/3.2.2-gentoo/ directory? Maybe /usr/include/zfs/ would > be better place? That directory contains what would be in the kernel sources directory had these modules been in tree. The most appropriate location is in /usr/src. I am marking this bug resolved.
Thanks.