Package: libplayeronecamera2t64 Version: 3.1.0+20221218103507-2 Severity: serious User: helm...@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: z...@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
