zfs-devel ends up requiring a new kernel? #2329
Comments
|
If you use the DKMS version of the ZFS package it provides zfs-kmod without being tied to any specific kernel version. The problem is the ZFS tools are useless without some kind of kernel driver. Even the pure user-space tools like zdb and ztest require putting their hands on /dev/zfs (arguably this could be a bug). zfs-devel needs zfs because it contains symlinks pointing to shared objects from it. |
|
zfs-devel requires zfs because it contains symlinks for the unversioned shared system library files. This was done in accordance with the official fedora packaging guidelines, see: http://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages zfs is tried to zfs-kmod because the utilities require the You can always install the packages with '--nodeps' manually. But the dependencies listed are very real. |
|
Right. -devel packages usually need to depend on whatever library has the versioned libs in it. I'm not sure what the Fedora packaging guidelines have to say about it (I don't recall it specifically talking about library-only packages, either pro or con), but it seems to me that the resolution here, to prevent wanting zfs-devel and having to take a whole new kernel (and a modules package, unnecessarily increasing the footprint) is to separate out the versioned libs from the zfs package into a zfs-libs or libzfs, (or whatever) sub-package and then have zfs-devel and zfs both depend on that. Yes, I know it's package proliferation but that's what we have tools like yum and apt for, and IMHO, another sub-package is miles and miles better than forcing a kernel and modules onto somebody who just wants -devel. |
I completely agree, it should have been done that way originally. The packaging guidelines for Debian, Ubuntu, and Fedora all agree on this. It's the only clean way to support version libraries. If you want to propose a patch which creates the following subpackages we could get it reviewed. These would all need -devel package of course. libzpool2 We might be able to move the following libraries in to a common libspl1. Although splitting them out is arguable the right thing. libavl1 |
Due to the change for with-zfs-devel (LU-3497), also add support to
search for libzfs.so along with the alternate locations supplied with
the header files.
Also need to unpack zfs{,-devel}. The zfs RPM is needed because it
has the actual libraries in it and the zfs-devel RPM only has un-
versioned symlinks to the libraries in the zfs RPM.
This will all change one day when we have a libzfs RPM per
openzfs/zfs#2329 and it looks like it
could be one day soon: openzfs/zfs#2341.
Signed-off-by: Nathaniel Clark <nathaniel.l.clark@intel.com>
Signed-off-by: Brian J. Murrell <brian.murrell@intel.com>
Change-Id: Ic78bd0eb88d8ab0f2456b8cf684bb8b9c0c0833a
Reviewed-on: http://review.whamcloud.com/10401
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: James Simmons <uja.ornl@gmail.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Closes: openzfs#2329 Rebase log: + Libraries doesn't need to depend on the zfs package. + Rename the devel package to libzfs2-devel and provide lib*-devel. This so that we can later separate the package into it's separate parts.
Closes: openzfs#2329 Rebase log: + Libraries doesn't need to depend on the zfs package. + Rename the devel package to libzfs2-devel and provide lib*-devel. This so that we can later separate the package into it's separate parts. + The devel should depend on the lib package, not the zfs package.
From day one the various ZFS libraries should have been placed in their own sub-packages. Primarily this allows for multiple major versions of the libraries to be concurrently installed. It also facilitates a smaller build environment by minimizing the required dependencies. The specific changes required to split the libraries from the utilities are as follows: * libzpool2, libnvpair1, libuutil1, and libzfs2 packages were added and contain the versioned shared libraries. The Fedora packaging guidelines discourage providing static libraries so they are not included in the packages. http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries * The zfs-devel package was renamed libzfs2-devel and the new package obsoletes the old zfs-devel package. This package includes all the required headers for the libzpool2, libnvpair1, libuutil1, and libzfs2 libraries and their respective unversioned shared libraries. This package should eventually be split in to individual lib*-devel packages but it will still take some work to cleanly separate them. Therefore the libzfs2-devel package provides the expected lib*-devel packages so the all proper dependencies can still be created. http://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages * Moved '/sbin/ldconfig' execution from the zfs packge to each of the new library packages as described by the packaging guidelines. http://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries * The /usr/share/doc/ files were moved in to the libzfs2-devel package. * Updated config/deb.am to be aware of the packaging changes. This ensures that 'deb-utils' make target converts all the resulting packages generated by the 'rpm-utils' target. Signed-off-by: Turbo Fredriksson <turbo@bayour.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes: #2329 Closes: #2341 Issue: #2145
|
@FransUrbo Thanks for proposing the patch. Another round of review and testing turned up a few more issue but I resolved them and merged your patch. It's nice to see this cleanly sorted out. Merged as: c9b5cc8 Move the libraries into separate packages |
Make mount/mkfs/tunefs functionality a per backing FSTYPE shared object that is loadable, and seperately buildable and installable in the appropriate lustre-osd-FSTYPE rpm. For ZFS this allows the shared object to be directly linked to libzfs and thus remove the hardcoding of a libzfs.so version in the lustre source. This also has the benefit of making lustre-osd-zfs explicitly requires libzfs (which it needs to do mount/mkfs operations). Adjust build system to allow building of loadable module. Including requiering libtool as part of the build. Lustre-change: http://review.whamcloud.com/10193 Lustre-commit: 3e8c354 LU-5091 build: Support alternate locations of libzfs.so Due to the change for with-zfs-devel (LU-3497), also add support to search for libzfs.so along with the alternate locations supplied with the header files. Also need to unpack zfs{,-devel}. The zfs RPM is needed because it has the actual libraries in it and the zfs-devel RPM only has un- versioned symlinks to the libraries in the zfs RPM. This will all change one day when we have a libzfs RPM per openzfs/zfs#2329 and it looks like it could be one day soon: openzfs/zfs#2341. Lustre-change: http://review.whamcloud.com/10401 Lustre-commit: b265903 Signed-off-by: Nathaniel Clark <nathaniel.l.clark@intel.com> Signed-off-by: Brian J. Murrell <brian.murrell@intel.com> Reviewed-by: James Simmons <uja.ornl@gmail.com> Reviewed-by: Oleg Drokin <oleg.drokin@intel.com> Change-Id: I1d69b64eec1589f63e24f20cc624778a4be2ec60 Reviewed-on: http://review.whamcloud.com/11297 Tested-by: Jenkins Tested-by: Maloo <hpdd-maloo@intel.com>
Due to the change for with-zfs-devel (LU-3497), also add support to
search for libzfs.so along with the alternate locations supplied with
the header files.
Also need to unpack zfs{,-devel}. The zfs RPM is needed because it
has the actual libraries in it and the zfs-devel RPM only has un-
versioned symlinks to the libraries in the zfs RPM.
This will all change one day when we have a libzfs RPM per
openzfs/zfs#2329 and it looks like it
could be one day soon: openzfs/zfs#2341.
Signed-off-by: Nathaniel Clark <nathaniel.l.clark@intel.com>
Signed-off-by: Brian J. Murrell <brian.murrell@intel.com>
Change-Id: Ic78bd0eb88d8ab0f2456b8cf684bb8b9c0c0833a
Reviewed-on: http://review.whamcloud.com/10401
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: James Simmons <uja.ornl@gmail.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
There is a dependency chain from zfs-devel that winds up in requiring a kernel through:
zfs-devel -> zfs -> zfs-kmod -> kernel
One really ought not to have to be tied to a particular run-time kernel just to get a -devel package.
Why does zfs-devel depend on zfs? That seems to be where trouble starts.
The text was updated successfully, but these errors were encountered: