On Sun, Oct 08, 2023 at 01:42:05PM +0300, Martin-Éric Racine wrote: > On Sun, 8 Oct 2023 08:15:40 +0200 Helmut Grohne <hel...@subdivi.de> wrote: > > Unfortunately, the stable update of dhcpcd5 introduced a regression > > relevant to upgrades from bullseye. The bullseye dhcpcd5 package > > contained the files > > - /lib/dhcpcd/dhcpcd-hooks/01-test > > - /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf > > - /lib/dhcpcd/dhcpcd-hooks/30-hostname > > - /lib/dhcpcd/dhcpcd-hooks/60-ntp-common.conf > > - /lib/dhcpcd/dhcpcd-hooks/62-chrony.conf > > - /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf > > - /lib/dhcpcd/dhcpcd-hooks/68-openntpd.conf > > - /lib/dhcpcd/dhcpcd-run-hooks > > and these have been moved into dhcpcd-base in that particular stable > > update. The update correctly declares Replaces for this. Unfortunately, > > it also moves these files from /lib to /usr/lib. Therefore, the declared > > Replaces have no effect (regarding these files) and as a consequence, an > > upgrade may delete the affected files. > > That doesn't hold water. Moving files to the base package doesn't delete them.
This issue is specific to /usr-merged systems (and this is mandatory in bookworm). It cannot be experienced on unmerged installations. In particular, if you delete the usrmerge package installation from my reproducer, it no longer reproduces. The problem arises from dpkg not being aware of wlog /lib/dhcpcd/dhcpcd-run-hooks and /usr/lib/dhcpcd/dhcpcd-run-hooks being the same file on disk. So when you unpack the updated dhcpcd-base, it'll replace the affected file, but not take it over from dhcpcd5 (because it is recorded with a different name there). As you remove (or upgrade) dhcpcd5, dpkg will delete it - not realizing that it is deleting a file (with a different name) from dhcpcd-base. We have violated a core assumption of dpkg and this is why Replaces have become insufficient. > Thus changing fields from what to what? -Replaces: dhcpcd5 (<< 9.4.1-2) -Breaks: dhcpcd5 (<< 9.4.1-2) +Conflicts: dhcpcd5 (<< 9.4.1-2) The conflict implies a break and since it also prevents concurrent unpack, no replacement can ever happen. Helmut
