Package: libzfs6linux Version: 2.3.0~rc5-1~exp1 Severity: serious Justification: file loss in upgrade User: helm...@debian.org Usertags: dep17p1
Hi, the files - /usr/lib/x86_64-linux-gnu/libzfs_core.so.3 - /usr/lib/x86_64-linux-gnu/libzfs_core.so.3.0.0 are installed by both libzfs6linux and by libzfs4linux. As a result, libzfs6linux declares Replaces: libzfs4linux. Unfortunately, libzfs4linux used to install these files below /lib until bookworm. As such, an upgrade from bookworm to experimental may loose these files. The issue arises from the /usr-move transition that requested moving these files from /lib to /usr/lib. For details on the problem category refer to https://subdivi.de/~helmut/dep17.html section P1. Until you move libzfs6linux to unstable, this is not a practical problem, because we consider upgrades from bookworm to experimental unsupported. If libzfs6linux is not meant to be part of trixie (but a preparation for forky), there is no relevant upgrade path as we expect bookworm users to first upgrade to trixie before upgrading to forky. In that case, please close this bug report. Otherwise, libzfs6linux has been added for preparing an update for trixie. In this case, we must add mitigations. DEP17 suggests multiple mitigations for this. In order to select a suitable one, I would like to understand whether this library is potentiall involved in system boot. In other words whether we risk turning a system unbootable if the library would go missing. If that is the case, I suggest using a more elaborate mitigation. I intend to provide the relevant patches (if any). To provide suitable patches, I depend on feedback: * Is libzfs6linux meant to be included in trixie? * If yes, do you see a risk of rendering a system unbootable if libzfs_core.so.3 would go missing? Thanks in advance Helmut
