[Pkg-zfsonlinux-devel] Bug#1092598: Bug#1092598: libzfs6linux ineffectively replaces libzfs4linux (DEP17 P1)

[Helmut Grohne]

Hi Shengqi Chen,

On Sat, Jan 11, 2025 at 12:02:32AM +0800, Shengqi Chen wrote:
> Maybe a newbie question -- I am not that familiar with how dpkg-divert works.

I still noticed a week ago that I am not familiar with how dpkg-divert
works and had to send an embarrasing mail to d-devel about it. (:

> You wrote “--no-rename”, ASAIK that means no actual file move would happen.

This indeed is intentional.

> So how does this affect dpkg’s removal behavior of unmerged libzfs4linux?

Unmerged /usr is no longer supported at all. Since Debian bookworm, we
assume that all systems are merged. On the flip side this means that the
change must not be backported to bookworm.

> Will it still try to remove /lib/xxx/libzfs_core.so <http://libzfs_core.so/>.3.usr-is-merged (as a no-op)?

Yes. If you were to run this on an unmerged system, libzfs6linux.preinst
were diverting the file (without renaming), then you'd unpack
libzfs6linux and remove libzfs4linux (thus keeping libzfs4linux'
libzfs_core.so.3 around as the removal is redirected) and you'd end up
with libzfs4linux' libzfs_core.so.3 at /lib/xxx and libzfs6linux'
libzfs_core.so.3 at /usr/lib/xxx. I suspect the dynamic loader would
pick up the /lib/xxx one first. If you (for some reason) wish to support
the unmerged case, libzfs6linux.postinst could check whether /lib is a
symlink and remove /lib/xxx/libzfs_core.so.3 when not.

So yeah, skip upgrades very much are unsupported.

Let me know if you have further questions.

Helmut