[Debian-astro-maintainers] Bug#1076374: libplayeronecamera2t64: ineffective replaces for /usr/lib/udev/rules.d/99-player_one_astronomy.rules causes file loss

[Helmut Grohne]

Package: libplayeronecamera2t64
Version: 3.1.0+20221218103507-2
Severity: serious
User: helmutg at debian.org
Usertags: dep17p1
Control: clone -1 -2
Control: retitle -2 libplayeronecamera2t64: soname-independent file in shared libarary package
Control: affects -1 libplayeronecamera2
X-Debbugs-Cc: zeha at debian.org

Hi Thorsten,

thank you for applying our /usr-move patches. Unfortunately, this one
went wrong and it went to unstable rather than experimental.

libplayeronecamera2 installs
/lib/udev/rules.d/99-player_one_astronomy.rules in bookworm and
currently also trixie. libplayeronecamera2t64 installs the same file to
the corresponding canonical location. Upgrading from bookworm or trixie
to unstable is thus prone to loosing this file. Refer to DEP17 P1 for
more details on the problem class. I file this at rc severity to prevent
testing migration and to help apt-listbugs users.

I note that the name of the udev rules file does not depend on the
soname of the library. Hence, doing a soname bump would cause a file
conflict between shared libraries that are supposed to be coinstallable.
This constitutes a policy violation and I have cloned a separate bug for
this very aspect.

I see multiple possible solutions to these two related bugs and ask you
for help with picking a suitable for this very instance.

For resolving the policy violation, we have two options. One is
introducing a soname-independent -common package and moving the rules
file there. The other is renaming the rules file and making its name
dependent on the soname (and optionally also dependent on the t64
suffix). These options have different implications and trade-offs. The
rules filename is a user-visible aspect as people are entitled to
override this file by creating a corresponding one below /etc. Changing
the name, renders their override ineffective. If you anticipate
overriding, you should not choose the renaming approach and few packages
actually select it. If you choose the renaming approach, you no longer
have to declare Replaces for this very file and as a consequence, you
may close the "ineffective replaces" bug with no further action. If
instead you choose the -common pacakege, said -common package will have
to declare Replaces for libplayeronecamera2 and libplayeronecamera2t64
and will inherit the "ineffective replaces" problem for
libplayeronecamera2.

If you end up keeping the "ineffective replaces" problem (by not
renaming the rules file) whatever package ends up containing it will
require a DEP17 mitigation. Given that this almost is a leaf package
with few installations, I argue that a less reliably mitigation is
ok-ish. If the package containing the rules (libplayeronecamera2t64 or
the -common one) upgrades its "Replaces: libplayeronecamera2" to
"Conflicts; libplayeronecamera2", the file loss will be mitigated for
all users that happen to use apt or aptitude (or any other manager based
on libapt) rather than doing their dist-upgrade using dpkg
--auto-deconfigure --unpack somefile.deb. (I am not aware of anyone
doing such manual dpkg work beyon Ian Jackson's double-skip upgrade
adventure.) And since the loss is not critical to booting their system,
it can be recovered by reinstalling the affected package. The benefit of
this is that your maintenance cost of this mitigation is fairly low. Do
you agree that the proposed risk is reasonable?

If you feel that a stronger mitigation is necessary, I can supply a
patch adding protective diversions (via maintainer scripts).

Please let me know your preference. Roughly speaking your options now
are:
 * rename the rules file (closing both bugs)
 * move the rules file to a -common package (closing the -2 bug)
 * upgrade Replaces to Conflicts (closing the -1 bug)
 * request diversion-based mitigation (closing the -1 bug)

Thanks for bearing with the /usr-move folks!

Helmut