Helmut, Thanks for quick and effective response. Yes, this is a bug.
Below is my current thought: On Wed, 2025-04-23 at 07:19 +0200, Helmut Grohne wrote: > Hi Osamu, > ... > mmdebstrap ... && apt-get download debian-reference-de && dpkg --unpack -- > auto-deconfigure *.deb && apt-get -y -f install && dpkg --verify' > ... > > W: Download is performed unsandboxed as root as file '//debian-reference- > > de_2.125_all.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run > > (13: Permission denied) > I vaguely agree. We're looking into bookworm to trixie upgrades now. > ... > The dpkg-maint-helper addresses the issue of symlink <-> directory > conversion within one package. What makes it "fail" here is that > multiple packages are involved and we are installing files beneath a > location that formerly was a symbolic link. English text parser in my brain was not good enough to understand this "problematic unpack order" event explained in the original bug report. This log and your updated message made me aware of the real issue. Thanks. I think my previous fix was well intended but agree it was a half-ass fix. It looks like the maintscript needs to be added to all debian-reference-* binary packages including debian-reference-de to switch symlink to directory no matter what is the order of unpacking. (Currently only with debian-reference-common has it.) According to dpkg-maint-helper: > Current implementation: the preinst checks if the symlink exists and points > to old-target, if not then it's left in place, otherwise it's renamed to > pathname.dpkg-backup. On configuration, the postinst removes > pathname.dpkg-backup if pathname.dpkg-backup is still a symlink. On > abort-upgrade/abort-install, the postrm renames pathname.dpkg-backup back > to pathname if required. So repeated invocation maintscript by all debian-reference-* packages should not cause trouble. Let me test this fix and upload. Best regards, Osamu
