Hi, Helmut,

I am not sure if this bug really exists?

FYI: If this bug exists, it is around the current usage of dpkg-maint-helper(1).

Helmut, please respond to the following for me to proceed with this bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100677

I assumed Helmut (this bug report) rigorously tested for the current packages. I
also looked into the solution in rush before sending my initial response. But I
felt a bit awkward, to be honest now. So I left the solution in VCS commit only
at this moment.

Some facts:

* 2.100 BOOKWORM version
* 2.109 BUG causing version
* 2.115 BUG fix version using dpkg-maint-helper(1)
* 2.125 CURRENT testing version

These point me to think this bug shouldn't exist, now.

Please note I am not asserting the bug reporter didn't encounter problem. Bug fix like this can't ensure broken system upgraded from 2.100 to 2.114. The packaging scripts are not be required to address such broken system. Fixing such broken system are usually left to the system admin using 2.109-2.144.

As I re-read this bug report, Helmut only presented possible "undeclared file conflict" but had no actual incident log proof to back it up on the current version.

I know this is a complicated packaging task situation and want to be absolutely sure. So, please help me with the followings by providing reproducible bug example log on the testing package.

If bug exists, I will test updated fix with it.

As for the possible "undeclared file conflict" mentioned, it's a complicated situation for which Debian dpkg developers recommend us to use their elegant dpkg-maint-helper(1) to address it without ugly pre-depends. I fixed this bug in 2.115 using this dpkg-maint-helper(1) trick.

You can see this dpkg-maint-helper(1) used in debian/debian-reference- common.maintscript: (original commit) https://salsa.debian.org/debian/debian-reference/-/blob/4e6768c41543ff427568b999c3ffcf0afb76cfb7/debian/debian-reference-common.maintscript

As for "Pre-Depends: dpkg (>= 1.17.14)" mentioned in the dpkg-maint-helper(1) manpage, I skipped it since all current usable dpkg are:

* oldstable: 1.20.13
* old-sec: 1.20.10
* stable: 1.21.22
* testing: 1.22.18
* unstable: 1.22.18

Best regards,

Osamu

PS: This reminds me to add some easy-to-find reminder in debmake-doc to make it
easy to find the usage of dpkg-maint-helper(1)

PPS: If the existing fix is good enough, I shouldn't make un-needed and redundant changes in 2.126.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Osamu,

On Wed, Apr 23, 2025 at 11:50:42AM +0900, Osamu Aoki wrote:

I am not sure if this bug really exists?

FYI: If this bug exists, it is around the current usage of dpkg-maint-helper(1).

Thanks for having looked into this problem in depth.

Helmut, please respond to the following for me to proceed with this bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100677

I assumed Helmut (this bug report) rigorously tested for the current packages. I
also looked into the solution in rush before sending my initial response. But I
felt a bit awkward, to be honest now. So I left the solution in VCS commit only
at this moment.

Some facts:

* 2.100 BOOKWORM version
* 2.109 BUG causing version
* 2.115 BUG fix version using dpkg-maint-helper(1)
* 2.125 CURRENT testing version

These point me to think this bug shouldn't exist, now.

Rather than analyze the problem, we may look at it empirically. Can we reproduce it?

The problem at hand is that bookworm's debian-reference-common contains
a symbolic link that later becomes a directory in debian-reference-de
(wlog) while there is no relation ensuring good unpack order.

mmdebstrap --variant=apt '' /dev/null 'deb http://deb.debian.org/debian bookworm main' --include=debian-reference-common --chrooted-customize-hook='sed -i -e s/bookworm/trixie/ /etc/apt/sources.list && apt-get update && apt-get download debian-reference-
de && dpkg --unpack --auto-deconfigure *.deb && apt-get -y -f install && dpkg --verify'

| I: running --chrooted-customize-hook in shell: sh -c 'sed -i -e s/bookworm/trixie/ /etc/apt/sources.list && apt-get update && apt-get download debian-reference-de && dpkg --unpack --auto-deconfigure *.deb && apt-get -y -f install && dpkg --verify'
| Get:1 http://deb.debian.org/debian trixie InRelease [175 kB]
| Get:2 http://deb.debian.org/debian trixie/main amd64 Packages [9687 kB]
| Fetched 9863 kB in 1s (9441 kB/s)
| Reading package lists... Done
| Get:1 http://deb.debian.org/debian trixie/main amd64 debian-reference-de all 2.125 [1927 kB]
| Fetched 1927 kB in 0s (67.7 MB/s)
| 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)
| Selecting previously unselected package debian-reference-de.
| (Reading database ... 6748 files and directories currently installed.)
| Preparing to unpack debian-reference-de_2.125_all.deb ...
| Unpacking debian-reference-de (2.125) ...
| Reading package lists... Done
| Building dependency tree... Done
| Reading state information... Done
| Correcting dependencies... Done
| The following additional packages will be installed:
| debian-reference-common
| Suggested packages:
| calibre debian-reference debian-reference-en debian-reference-es debian-reference-fr debian-reference-id debian-reference-it debian-reference-ja debian-reference-pt
| debian-reference-zh-cn debian-reference-zh-tw mc vim
| Recommended packages:
| w3m | www-browser
| The following packages will be upgraded:
| debian-reference-common
| 1 upgraded, 0 newly installed, 0 to remove and 77 not upgraded.
| 1 not fully installed or removed.
| Need to get 37.7 kB of archives.
| After this operation, 7168 B of additional disk space will be used.
| Get:1 http://deb.debian.org/debian trixie/main amd64 debian-reference-common all 2.125 [37.7 kB]
| Fetched 37.7 kB in 0s (3312 kB/s)
| (Reading database ... 6771 files and directories currently installed.)
| Preparing to unpack .../debian-reference-common_2.125_all.deb ...
| Unpacking debian-reference-common (2.125) over (2.100) ...
| dpkg: warning: unable to delete old directory '/usr/share/debian-reference': Directory not empty
| Setting up debian-reference-common (2.125) ...
| Setting up debian-reference-de (2.125) ...
| missing /usr/share/doc/debian-reference-common/docs/apa.de.html
| missing /usr/share/doc/debian-reference-common/docs/ch01.de.html
| missing /usr/share/doc/debian-reference-common/docs/ch02.de.html
| missing /usr/share/doc/debian-reference-common/docs/ch03.de.html
| missing /usr/share/doc/debian-reference-common/docs/ch04.de.html
| missing /usr/share/doc/debian-reference-common/docs/ch05.de.html
| missing /usr/share/doc/debian-reference-common/docs/ch06.de.html
| missing /usr/share/doc/debian-reference-common/docs/ch07.de.html
| missing /usr/share/doc/debian-reference-common/docs/ch08.de.html
| missing /usr/share/doc/debian-reference-common/docs/ch09.de.html
| missing /usr/share/doc/debian-reference-common/docs/ch10.de.html
| missing /usr/share/doc/debian-reference-common/docs/ch11.de.html
| missing /usr/share/doc/debian-reference-common/docs/ch12.de.html
| missing /usr/share/doc/debian-reference-common/docs/debian-reference.de.pdf
| missing /usr/share/doc/debian-reference-common/docs/debian-reference.de.txt.gz
| missing /usr/share/doc/debian-reference-common/docs/index.de.html
| missing /usr/share/doc/debian-reference-common/docs/pr01.de.html

I explicitly triggered a bad unpack order here and as a result, debian-reference-common's symbolic link redirected debian-reference-de's
files such that when the upgrade is complete, they end up missing.

I only see three ways to get around this:
* debian-reference-de Pre-Depends debian-reference-common (>= ...) to
ensure the correct unpack order.
* debian-reference-de Conflicts debian-reference-common (<< ...) to
ensure the correct unpack order.
* debian-reference-de takes care of removing debian-reference-common's
symbolic link in its own preinst.

Please note I am not asserting the bug reporter didn't encounter problem. Bug
fix like this can't ensure broken system upgraded from 2.100 to 2.114. The packaging scripts are not be required to address such broken system. Fixing such broken system are usually left to the system admin using 2.109-2.144.

I vaguely agree. We're looking into bookworm to trixie upgrades now.

As I re-read this bug report, Helmut only presented possible "undeclared file conflict" but had no actual incident log proof to back it up on the current version.

I think we now have.

As for the possible "undeclared file conflict" mentioned, it's a complicated situation for which Debian dpkg developers recommend us to use their elegant dpkg-maint-helper(1) to address it without ugly pre-depends. I fixed this bug
in 2.115 using this dpkg-maint-helper(1) trick.

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.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)