[Pkg-zfsonlinux-devel] Bug#880709: zfsutils-linux 0.7.3 has an unlisted dependency on libuutil1linux >= 0.7.3

[Fabian Grünbichler]

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 ;)