[Debian-astro-maintainers] Bug#1072730: libfishcamp1t64: ineffective Replaces due to /usr-move (DEP17)

[Helmut Grohne]

Package: libfishcamp1t64
Version: 1.2+20220607003151-2
Severity: serious
Tags: patch
User: helmutg at debian.org
Usertags: dep17p1
Control: clone -1 -2
Control: retitle -2 violates policy 8.2: soname-independent library support files

Hi Thorsten,

I am sorry to tell you that libfishcamp1t64 slipped through my review.
It really is one of the packages that cannot be just moved. I'll review
my analysis regarding this after sending this patch.

libfishcamp combines three ingredients:
 * It installed aliased files in bookworm (firmware and udev rules)
 * It is affected by the time64 transition and thus renames packages.
 * It installs files that are not soname-dependent into the shared
   library package violating Debian policy section 8.2. I've cloned a
   separate bug about this problem.

As a result, you are experiencing a DEP17 P1 problem. Roughly speaking,
an upgrade could first unpack libfishcamp1t64 thereby installing the
firmware and udev files into /usr. In doing so, dpkg overwrites the
files from libfishcamp1 without attributing it to Replaces due to the
difference in aliasing. Then, when libfishcamp1 is removed, it also
removes firmware and udev files for real as they have not been replaced.
Once the upgrade is complete, these files go missing.

So this is indeed a case where dh-sequence-movetousr does not just work
(and maybe it now becomes more clear why we didn't make
dh-sequence-movetousr opt-out). There are multiple options to mitigate
this with varying level of reliability. A reliable mitigation requires
using protective diversions installed for the entire trixie release.
This is fairly annoying and causes maintenance costs down the road
(removing diversions, later removing diversion removing code). I propose
using a less reliable method for this case. fishcamp seems to be a
relatively unpopular package, so the number of affected users is
expected to be small. When upgrading the Breaks to Conflicts (without
having reverse Breaks), we are not aware of any scenario where this
mitigation would be unreliable when using apt or aptitude (i.e. you need
to install libfishcamp1t64 using dpkg directly in a specific setting to
actually experience file loss). In any case, users can detect the loss
using dpkg --verify and reinstalling libfishcamp1t64 will reinstate the
lost files. Loss of these files would likely not render systems
unbootable. Hence, I think this is a relatively low probability,
relatively low impact and the more reliable mitigation has significantly
higher maintenance cost.

Do you agree with this risk assessment? If not, I can provide a more
elaborate patch doing a more reliable mitigation.

Another alternative to fixing this problem is reverting the t64
transition. I looked for the abi report, but there is none nor is there
a bug report from the t64 people. Hence, I looked at the headers and
found that none of them use off_t or time_t or other relevant types in
structures or types. time_t is used internally, but not exposed. As a
result, fishcamp very likely is unaffected by the time64 transition and
its rename can be reverted. The revert briefly introduces the reverse
DEP17 P1 problem into unstable, but for bookworm -> trixie upgrades,
things would work then. If you opt for reverting, you don't have to use
Conflicts and you can continue to use dh-sequence-movetousr.

I note that the attached patch is not appropriate for bookworm-backports
(but neither is the t64 rename).

Helmut
-------------- next part --------------
diff --minimal -Nru libfishcamp-1.2+20220607003151/debian/changelog libfishcamp-1.2+20220607003151/debian/changelog
--- libfishcamp-1.2+20220607003151/debian/changelog	2024-06-03 23:30:36.000000000 +0200
+++ libfishcamp-1.2+20220607003151/debian/changelog	2024-06-07 10:14:24.000000000 +0200
@@ -1,3 +1,12 @@
+libfishcamp (1.2+20220607003151-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mitigate /usr-move DEP17 P1 problems. (Closes: #-1)
+    + Manually move files instead of using dh-sequence-movetousr.
+    + Upgrade Breaks to Conflicts.
+
+ -- Helmut Grohne <helmut at subdivi.de>  Fri, 07 Jun 2024 10:14:24 +0200
+
 libfishcamp (1.2+20220607003151-2) unstable; urgency=medium
 
   * upload to unstable
diff --minimal -Nru libfishcamp-1.2+20220607003151/debian/control libfishcamp-1.2+20220607003151/debian/control
--- libfishcamp-1.2+20220607003151/debian/control	2024-06-03 23:30:36.000000000 +0200
+++ libfishcamp-1.2+20220607003151/debian/control	2024-06-07 10:14:24.000000000 +0200
@@ -8,7 +8,6 @@
 	, libusb-1.0-0-dev
 	, zlib1g-dev
 	, libindi-dev
-	, dh-sequence-movetousr
 Standards-Version: 4.7.0
 Homepage: https://github.com/indilib/indi-3rdparty
 Rules-Requires-Root: no
@@ -19,7 +18,7 @@
 Package: libfishcamp1t64
 Provides: ${t64:Provides}
 Replaces: libfishcamp1
-Breaks: libfishcamp1 (<< ${source:Version})
+Conflicts: libfishcamp1 (<< ${source:Version})
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: library for cameras made by Fishcamp Engineering
diff --minimal -Nru libfishcamp-1.2+20220607003151/debian/libfishcamp1t64.install libfishcamp-1.2+20220607003151/debian/libfishcamp1t64.install
--- libfishcamp-1.2+20220607003151/debian/libfishcamp1t64.install	2024-06-03 23:30:36.000000000 +0200
+++ libfishcamp-1.2+20220607003151/debian/libfishcamp1t64.install	2024-06-07 10:14:24.000000000 +0200
@@ -1,4 +1,4 @@
 usr/lib/*/libfishcamp.so.*
-lib/firmware/gdr_usb.hex
-lib/firmware/Guider_mono_rev16_intel.srec
-lib/udev/rules.d/99-fishcamp.rules
+lib/firmware/gdr_usb.hex usr/lib/firmware/
+lib/firmware/Guider_mono_rev16_intel.srec usr/lib/firmware/
+lib/udev/rules.d/99-fishcamp.rules usr/lib/udev/rules.d/