2.1 libzpool5 deb relies on older libzfs4

[peterdk]

System information

Type	Version/Name
Distribution Name	Ubuntu
Distribution Version	21.10
Linux Kernel	5.11.0-22-generic
Architecture	x64
ZFS Version	2.1.0-1
SPL Version	2.1.0-1

Describe the problem you're observing

I build the 2.1 debs using make deb, and tried installing them. However, when installing libzpool5_2.1.0-1_amd64.deb I get the error that it needs libzfs4, while the deb generated is libzfs5 and it won't accept that one.

Describe how to reproduce the problem

make deb
dpkg -i *.deb (excluding devel and test packages)

Include any warning/errors/backtraces from the system logs

sudo dpkg -i libzfs5_2.1.0-1_amd64.deb libzpool5_2.1.0-1_amd64.deb 
(Reading database ... 500132 files and directories currently installed.)
Preparing to unpack libzfs5_2.1.0-1_amd64.deb ...
Unpacking libzfs5 (2.1.0-1) over (2.1.0-1) ...
Selecting previously unselected package libzpool5.
Preparing to unpack libzpool5_2.1.0-1_amd64.deb ...
Unpacking libzpool5 (2.1.0-1) ...
Setting up libzfs5 (2.1.0-1) ...
dpkg: dependency problems prevent configuration of libzpool5:
 libzpool5 depends on libzfs4; however:
  Package libzfs4 is not installed.

dpkg: error processing package libzpool5 (--install):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
Errors were encountered while processing:
 libzpool5

[peterdk]

I removed all zfs packages, did a rebuild, and now it somehow accepts the libzfs5. Apparently the build process looks to packages that are already installed? I don't understand why.

[filip-paczynski]

I removed all zfs packages, did a rebuild, and now it somehow accepts the libzfs5....

I've also experienced this exact scenario with 2.0.x. Nowadays I make sure to remove all zfs packages before building new ones. I agree it shouldn't be this way. However I lack sufficient knowledge on build systems to fix this, or even pin down specific cause.

[mskarbek]

Build in clean container with freshly installed build dependencies. It may be a slight inconvenience, but works.

[behlendorf]

I believe this may be a side effect of the project still using alien instead of native packaging for the deb. Until that changes (which I'm all for) you'll probably need to work around this, sorry for the inconvenience.

[rincebrain]

I got curious, and went down the rabbit hole - the short version is, I am pretty confident it is a consequence of using alien, and that just using native deb packaging is the most straightforward way to make this work properly.

alien as of the version I examined (8.95.4) does nothing with dependencies programmed into an rpm or deb when converting - it has bits for putting them in when you convert from one specific format, but AFAICT that's the only time it cares about ones you give it.

However, when emitting debs, it does include ${shlibs:Depends} in Depends, which gets filled in by the dh_shlibdeps call in the debian/rules file, which figures out what could match the symbols needed by the things in the package based on lists of symbols from installed packages.

Unfortunately, there's no existing way I see to avoid alien adding that or convince it to claim, say, libzfs5 provides all of libzfs1-9 - patching in something to convince it to optionally not do that or exclude certain things or w/e could be done, but that would take a while to land in distros, and I doubt it would get backported for existing releases just for this use case.

[Conan-Kudo]

For my workplace, we use an RPM spec file to build natively for RPM and Debian targets: https://pagure.io/openzfs-linux-packaging/blob/main/f/zfs.spec

Instead of using alien, we use debbuild.

We could probably adapt to using that instead if we wanted to...

[stale]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

[behlendorf]

Closing, I believe this should be addressed by #13451 when merged.

[almightiest]

@behlendorf this still happens with zfs 2.1.9 building on Ubuntu with 2.1.5 packages installed (alien causes packages to rely on libzfs4linux or other older packages). I had a hell of a time manually editing dependencies to fix apt before coming across this issue. Was that #13451 fixed for 2.1.x or 2.2.x?

[rincebrain]

That went into master and should be available for 2.2.x if you want to use it, though I confess I haven't tried since it was merged.

[thardie]

I just built the release version of 2.2.0 on a fresh install of Ubuntu 22.04 and ran into this error. It's not fixed.

[m-ueberall]

@thardie: Strange. Using make deb with a current version of rpm*, alien (local backports) to convert the "intermediate" rpm archives, I don't see any dependencies for libzpool5*.deb:

(ubuntu-focal-arm64)root@vserver21:/build/standalone/zfs# rpm --version
RPM version 4.18.0
(ubuntu-focal-arm64)root@vserver21:/build/standalone/zfs# alien -V
alien version 8.95.6~ubuntu20.04+projektzentrisch.de+1
(ubuntu-focal-arm64)root@vserver21:/build/standalone/zfs# ls ./lib*2.2.0*.deb
./libnvpair3_2.2.0-1_arm64.deb  ./libuutil3_2.2.0-1_arm64.deb  ./libzfs5-devel_2.2.0-1_arm64.deb  ./libzfs5_2.2.0-1_arm64.deb  ./libzpool5_2.2.0-1_arm64.deb
(ubuntu-focal-arm64)root@vserver21:/build/standalone/zfs# (for DEB in ./lib*2.2.0*.deb; do echo -n "$DEB -"; dpkg -I $DEB | grep Depends; echo; done) | grep Depends
./libnvpair3_2.2.0-1_arm64.deb - Depends: libc6 (>= 2.17)
./libuutil3_2.2.0-1_arm64.deb - Depends: libc6 (>= 2.17)
(ubuntu-focal-arm64)root@vserver21:/build/standalone/zfs#

(ubuntu-focal-amd64)root@vserver31:/build/standalone/zfs# rpm --version
RPM version 4.18.0
(ubuntu-focal-amd64)root@vserver31:/build/standalone/zfs# alien -V
alien version 8.95.6~ubuntu20.04+projektzentrisch.de+1
(ubuntu-focal-amd64)root@vserver31:/build/standalone/zfs# ls ./lib*2.2.0*.deb
./libnvpair3_2.2.0-1_amd64.deb  ./libuutil3_2.2.0-1_amd64.deb  ./libzfs5-devel_2.2.0-1_amd64.deb  ./libzfs5_2.2.0-1_amd64.deb  ./libzpool5_2.2.0-1_amd64.deb
(ubuntu-focal-amd64)root@vserver31:/build/standalone/zfs# (for DEB in ./lib*2.2.0*.deb; do echo -n "$DEB -"; dpkg -I $DEB | grep Depends; echo; done) | grep Depends
./libnvpair3_2.2.0-1_amd64.deb - Depends: libc6 (>= 2.14)
./libuutil3_2.2.0-1_amd64.deb - Depends: libc6 (>= 2.14)
(ubuntu-focal-amd64)root@vserver31:/build/standalone/zfs#

[rincebrain]

The bug is about how alien "helpfully" tries searching for your locally installed packages to resolve dependencies, so if you have pre-lib-increment packages installed, it will add dependencies on them when it transforms them, and bob's your uncle.

As of the last time I looked, alien has no flag to not do that, and I was several of the last few point releases fixing things in it, so I didn't feel like trying to add the feature to that nest of Perl. I'd usually suggest make native-deb as a better option, in 2.2, except, uh, #15404.

[jcferretti]

In case it helps anybody: I had this issue while trying to install packages built from 2.1.13 sources. The libzpool5_2.1.13-1_amd64.deb package had a dependency to libzfs4. I was able to "edit" the package to remove the dependency like this:

mkdir tmpdeb
cd tmpdeb
ar x ../libzpool5_2.1.13-1_amd64.deb   # will create 3 files: debian-binary, control.tar.zstd, data.tar.zstd
mkdir tmpcontrol
cd tmpcontrol
tar xf ../control.tar.zstd  # will create 4 files: control, md5sums, shlibs, triggers
vi control  # In the line that starts "Depends: ", preserve the format and remove the reference to libzfs4.
tar c md5sums control shlibs triggers | zstd -c > ../control.tar.zstd  # repack control
cd ..
ar rcs ../libzpool5_2.1.13-1_amd64.deb debian-binary control.tar.zstd data.tar.zstd # repack deb;  note file order is important

I had to do the same thing for zfs_2.1.13-1_amd64.deb

[rincebrain]

You could also just uninstall the old packages before doing the build, but yes, hand-editing the alien debs would work.

Or adding a feature to alien to let you exclude the autogenerated dependencies on the running system would do too.