Bug#880709: zfsutils-linux 0.7.3 has an unlisted dependency on libuutil1linux >= 0.7.3
On Thu, Nov 16, 2017 at 10:09:45AM -0500, Rich wrote: > I'm not sure I understand what you mean by symbol files for the libraries, > here - I know what symbols are, and usually I'd expect symbol files to > refer to something like external debug symbols, but it sounds like you're > suggesting something else? (usual disclaimer: I am NOT a/the maintainer of ZoL in Debian, just a (downstream) user making suggestions / contributing patches) symbols refers to symbols exported by the libraries and used by programs linking with them. a symbols file is a way to track changes (it basically lists the library version where a symbol was last changed in a breaking manner, or introduced if no such change has happened since then). it does mean a bit of additional overhead after importing upstream versions, to add new symbols and check existing ones for breaking changes (especially with an upstream like ZoL, where there are no versioned symbols / stable public ABI / ...). using a symbols file generated with 0.6.5.11-1 and updated using 0.7.3-1, this would generate the following versioned dependencies: zfsutils-linux -> libnvpair1linux, libuutil1linux >= 0.6.5.11-1 -> libzpool2linux, libzfs2linux >= 0.7.3-1 zfs-zed -> libnvpair1linux, libuutil1linux, libzpool2linux >= 0.6.5.11-1 -> libzfs2linux >= 0.7.3-1 zfs-test -> libnvpair1linux, libuutil1linux, libzfs2linux >= 0.6.5.11-1 -> libzpool2linux >= 0.7.3-1 libnvpair1linux -> libuutil1linux >= 0.6.5.11-1 libuutil1linux -> no new versioned dependencies libzfs2linux -> libnvpair1linux >= 0.6.5.11-1 -> libuutil1linux, libzpool2linux >= 0.7.3-1 libzpool2linux -> libnvpair1linux >= 0.6.5.11-1 -> libuutil1linux >= 0.7.3-1 which would have pulled in libuutil1linux on upgrades (on a system with zfsutils-linux installed, only libnvpair1linux would have stayed at 0.6.5.11-1 in a partial upgrade scenario). > > I'd pretty strongly suggest depending on identically versioned module, > since AFAIK the guarantee for what happens if you replace the userland and > not the kernel module even across point versions is "nothing". > > Of course, then you still have the problem of needing to reload the module > after replacing the userland, which you don't always get to do if you're > doing ZFS root... and verifying that the DKMS build was successful. in my experience, mixing user space and kernel modules within a release series works good enough to not force this dependency, but bumping it for major releases or known incompatibilities is a good idea for sure. the delta between minor releases is usually in the range of 10-20 commits, so checking those for (potential) issues is not that hard. > > Maybe it'd be a reasonable thing to do to try and get a patch upstream to > notice when userland and module version disagree and print a notice that > all bets are off. But then you'd need text processing to understand the > module versioning in each for anything but exact matching e.g. 0.7.3-1 > versus 0.7.3. also, I am not sure if there is a notion of 'version' for the userspace besides library sonames, which are not bumped often enough in ZoL to be reliable. I doubt upstream wants to check package versions ;) > > At a minimum, you'd want to depend on the same point version (e.g. 0.7.3-1 > and 0.7.3-2 should be fine to mix, unless we start integrating really > disruptive changes that aren't planned to go into the mainline version), > though we might want to just opt for exact version so we don't have to > worry about overlooking a change that would break this, but trying to do > that string processing wouldn't necessarily be portable or accepted > upstream (e.g. consider the versions emitted by git, IIRC of the form > 0.X.Y-g[git shorthash], and you _definitely_ don't want to mix across > those). see above > > Maybe just exact version matching for now (for both module/userland and > userland/dependent libraries) and an upstream enhancement request to notify > people they might set their house on fire if they mix differing > module/userland versions? I'll send a patch with symbols files for the library packages later today or on Monday, IMHO the rest is up to the maintainers ;)
Bug#880709: zfsutils-linux 0.7.3 has an unlisted dependency on libuutil1linux >= 0.7.3
I'm not sure I understand what you mean by symbol files for the libraries,
here - I know what symbols are, and usually I'd expect symbol files to
refer to something like external debug symbols, but it sounds like you're
suggesting something else?
I'd pretty strongly suggest depending on identically versioned module,
since AFAIK the guarantee for what happens if you replace the userland and
not the kernel module even across point versions is "nothing".
Of course, then you still have the problem of needing to reload the module
after replacing the userland, which you don't always get to do if you're
doing ZFS root...
Maybe it'd be a reasonable thing to do to try and get a patch upstream to
notice when userland and module version disagree and print a notice that
all bets are off. But then you'd need text processing to understand the
module versioning in each for anything but exact matching e.g. 0.7.3-1
versus 0.7.3.
At a minimum, you'd want to depend on the same point version (e.g. 0.7.3-1
and 0.7.3-2 should be fine to mix, unless we start integrating really
disruptive changes that aren't planned to go into the mainline version),
though we might want to just opt for exact version so we don't have to
worry about overlooking a change that would break this, but trying to do
that string processing wouldn't necessarily be portable or accepted
upstream (e.g. consider the versions emitted by git, IIRC of the form
0.X.Y-g[git shorthash], and you _definitely_ don't want to mix across
those).
Maybe just exact version matching for now (for both module/userland and
userland/dependent libraries) and an upstream enhancement request to notify
people they might set their house on fire if they mix differing
module/userland versions?
- Rich
On Thu, Nov 16, 2017 at 9:40 AM, Fabian Grünbichler <
f.gruenbich...@proxmox.com> wrote:
> On Sat, Nov 04, 2017 at 12:17:48AM -0400, Rich Ercolani wrote:
> > Package: zfsutils-linux
> > Version: 0.7.3-1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > As the subject says, if you just install
> > {zfsutils-linux,spl-dkms,zfs-dkms}/unstable,
> you can end up with libuutil1linux from stable or testing, and get back:
> > zpool: symbol lookup error: /lib/libzpool.so.2: undefined symbol:
> spl_pagesize
> > Explicitly installing libuutil1linux >= 0.7.3 resolves this, so the
> package should probably have an explicit version dependency listed.
> >
> > (As you can see, I commonly configure stable > testing > unstable
> pinning preferences, so booting a new stretch machine and installing the
> above with those pinnings will result in this.)
> >
> > - Rich
>
> I see two ways to go forward here:
> - add symbols files for the libraries and keep them uptodate
> - require libraries and utilities to have the exact same version
> (upstream does not guarantuee ABI/API stability yet AFAIK, only
> on-disk-format stability).
>
> I'll evaluate the symbols route tomorrow to see how much work it is
> (starting from 0.6.5.11-1).
>
> furthermore, the question of how to handle the userspace -> module
> dependency needs to be solved somehow. again, there are two basic
> possibilities:
>
> - add a versioned dependency to the same major version now, and bump it
> whenever incompatibilities are known
> - always depend on an identically versioned module
>
> thoughts?
>
>
Bug#880709: zfsutils-linux 0.7.3 has an unlisted dependency on libuutil1linux >= 0.7.3
On Sat, Nov 04, 2017 at 12:17:48AM -0400, Rich Ercolani wrote:
> Package: zfsutils-linux
> Version: 0.7.3-1
> Severity: important
>
> Dear Maintainer,
>
> As the subject says, if you just install
> {zfsutils-linux,spl-dkms,zfs-dkms}/unstable, you can end up with
> libuutil1linux from stable or testing, and get back:
> zpool: symbol lookup error: /lib/libzpool.so.2: undefined symbol: spl_pagesize
> Explicitly installing libuutil1linux >= 0.7.3 resolves this, so the package
> should probably have an explicit version dependency listed.
>
> (As you can see, I commonly configure stable > testing > unstable pinning
> preferences, so booting a new stretch machine and installing the above with
> those pinnings will result in this.)
>
> - Rich
I see two ways to go forward here:
- add symbols files for the libraries and keep them uptodate
- require libraries and utilities to have the exact same version
(upstream does not guarantuee ABI/API stability yet AFAIK, only
on-disk-format stability).
I'll evaluate the symbols route tomorrow to see how much work it is
(starting from 0.6.5.11-1).
furthermore, the question of how to handle the userspace -> module
dependency needs to be solved somehow. again, there are two basic
possibilities:
- add a versioned dependency to the same major version now, and bump it
whenever incompatibilities are known
- always depend on an identically versioned module
thoughts?
Bug#880709: zfsutils-linux 0.7.3 has an unlisted dependency on libuutil1linux >= 0.7.3
It appears that libzpool2linux is also an unlisted dependency. Merely having libuutil1linux installed was enough to clear the error of this bug but left "/sbin/zfs: symbol lookup error: /lib/libzfs.so.2: undefined symbol: SHA2Update" behind until libzpool2linux got added to the system. Cheers, --nwf; signature.asc Description: PGP signature
Bug#880709: zfsutils-linux 0.7.3 has an unlisted dependency on libuutil1linux >= 0.7.3
Package: zfsutils-linux
Version: 0.7.3-1
Severity: important
Dear Maintainer,
As the subject says, if you just install
{zfsutils-linux,spl-dkms,zfs-dkms}/unstable, you can end up with libuutil1linux
from stable or testing, and get back:
zpool: symbol lookup error: /lib/libzpool.so.2: undefined symbol: spl_pagesize
Explicitly installing libuutil1linux >= 0.7.3 resolves this, so the package
should probably have an explicit version dependency listed.
(As you can see, I commonly configure stable > testing > unstable pinning
preferences, so booting a new stretch machine and installing the above with
those pinnings will result in this.)
- Rich
-- System Information:
Debian Release: 9.2
APT prefers stable
APT policy: (1000, 'stable'), (900, 'testing'), (800, 'unstable'), (500,
'stable-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages zfsutils-linux depends on:
ii libblkid12.29.2-1
ii libc62.24-11+deb9u1
ii libnvpair1linux 0.7.3-1
ii libuuid1 2.29.2-1
ii libuutil1linux 0.6.5.9-5
ii libzfs2linux 0.7.3-1
ii libzpool2linux 0.7.3-1
ii python3 3.5.3-1
ii zlib1g 1:1.2.8.dfsg-5
Versions of packages zfsutils-linux recommends:
ii lsb-base9.20161125
ii zfs-dkms [zfs-modules] 0.7.3-1
ii zfs-zed 0.7.3-1
Versions of packages zfsutils-linux suggests:
pn nfs-kernel-server
pn samba-common-bin
pn zfs-initramfs | zfs-dracut
-- no debconf information
