Bug#1055484: libpam-elogind-compat has ineffective replaces for libpam-systemd due to /usr-merge
Control: block -1 1055562 Helmut, On Tue, Nov 07, 2023 at 08:39:23AM +, Mark Hindley wrote: > I think all suitable dependencies now use default-logind | logind. I will > check that is correct. If it is, libpam-elogind-compat could just be > removed. It was never available outside experimental. AFAICS, all supported cases now use Depends: default-logind | logind or have demoted the Depends to Recommends. I have filed a RM request[1]. Mark [1] https://bugs.debian.org/1055562
Bug#1055484: libpam-elogind-compat has ineffective replaces for libpam-systemd due to /usr-merge
On Tue, 7 Nov 2023, Helmut Grohne wrote: >Do you know why Breaks+Replaces has been chosen here? Do you see any >issues with upgrading to Conflicts? Probably because lintian indicates that that should be the normal thing to do in such cases, and before UsrMove it was the working thing, too… bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1055484: libpam-elogind-compat has ineffective replaces for libpam-systemd due to /usr-merge
Helmut, Thanks for this. libpam-elogind-compat was used when elogind was first introduced as a hack to circumvent missing dependencies and allow testing. I think all suitable dependencies now use default-logind | logind. I will check that is correct. If it is, libpam-elogind-compat could just be removed. It was never available outside experimental. Mark
Bug#1055484: libpam-elogind-compat has ineffective replaces for libpam-systemd due to /usr-merge
Package: libpam-elogind-compat Version: 1.3 Severity: serious Justification: silent file overwrite in upgrade situation User: helm...@debian.org Usertags: dep17p1 Control: clone -1 -2 Control: affects -1 + libpam-systemd Control: retitle -2 libpam-systemd needs a versioned conflict for libpam-elogind-compat Control: reassign -2 libpam-systemd Control: found -2 255~rc1-2 Control: affects -2 + libpam-elogind-compat Control: block -2 by -1 libpam-elogind-compat declares "Replaces: libpam-systemd", because they both install e.g. /lib/x86_64-linux-gnu/security/pam_systemd.so on amd64. Since libpam-systemd/255~rc1-2 in experimental, this file is located in the corresponding location below /usr. Therefore the Replaces declaration is not matched by dpkg and becomes ineffective. The resulting behaviour is as if there was no replaces. This is problem class is described in more detail in DEP17[1] P1. The simplest mitigation for this kind of problem is preventing concurrent unpack by upgrading Replaces to Conflicts (and thus dropping the now implied Breaks). This mitigation is described in more detail in DEP17[1] M7. Do you know why Breaks+Replaces has been chosen here? Do you see any issues with upgrading to Conflicts? A timely solution is appreciated, because libpam-systemd will need a versioned Conflicts on unfixed versions of libpam-elogind-compat to avoid breaking upgrades. Helmut [1] https://subdivi.de/~helmut/dep17.html
