On Tue, Apr 29, 2025 at 11:02:04AM +0900, Osamu Aoki wrote:
> I still see APT warning in your updated test install log.
That's purely from apt-get download. We may separate the invocations to
make the source apparent.
> Are you insisting that "Preparing to unpack" process run under warned
> condition
> is a valid test case to warrant declaring pre-depends against the policy
> guidance.
I am insisting that the warning comes from apt-get download and not from
dpkg and that dpkg is not run by apt here. The unpack condition is
otherwise valid.
> "Preparing to unpack" runs preinst in advance. If this process is run by
> _apt,
> it may be unable to find preinst and skipped. This may be the case in your
> test
> case due to this permission problem.
It is not run by _apt.
> > Unpacking debian-reference-de (2.126) ...
>
> It looks like it failed since preinst script was skipped when it really meant
> to
> be executed.
The preinst script was run, but the helper concluded that it should not
act.
> > This is closely following my reproducer. At this point, the damage
> > should be there. Whilst, debian-reference-de.preinst attempts to perform
> > the link to directory conversion, the link is owned by the "wrong"
> > package and hence the helper does not act. At this point, dpkg --verify
> > should tell you about missing files.
> >
>
> You say "should". But really? I don't see such problem in my test case
> since
> debian-reference-de.preinst is accessible and executed. Here is the
> situation:
>
> > osamu@goofy:~/salsa/debian-reference/test 10:19:23 ↵
> > $ sudo dpkg --unpack --auto-deconfigure debian-reference-de_2.126_all.deb
> > (Reading database ... 636574 files and directories currently installed.)
> > Preparing to unpack debian-reference-de_2.126_all.deb ...
> > Unpacking debian-reference-de (2.126) over (2.126) ...
> > Processing triggers for doc-base (0.11.1) ...
> > Processing 1 changed doc-base file...
> > osamu@goofy:~/salsa/debian-reference/test 10:21:20 ↵
> > $ ls -l /usr/share/doc/debian-reference-common/
> > total 24
> > -rw-r--r-- 1 root root 6616 Apr 24 11:18 changelog.gz
> > -rw-r--r-- 1 root root 1430 Apr 24 11:18 copyright
> > drwxr-xr-x 1 root root 548 Apr 29 10:20 docs
> > -rw-r--r-- 1 root root 8893 Apr 24 11:18 README.md.gz
> > osamu@goofy:~/salsa/debian-reference/test 10:21:28 ↵
Now this is where it truly gets interesting. Thanks for adding that ls
-l output at the right spot: You run it after the unpacking of
debian-reference-de before the unpacking of debian-reference-common
which is exactly the spot where I claim the problem to occur.
I still cannot reproduce your output. There are two sensible options I
see here. Either, the dpkg-maintscript-helper acted. Then it will have
backed up the docs symlink and thus there should be a link
"docs.dpkg-backup". Evidently this is not the case for you. The other
option is that it has not acted and then "docs" should be a symlink. In
no case does dpkg-maintscript-helper delete the docs link during
preinst. This strongly suggests that your test environment was not in a
sane state at the beginning.
> I see "own" reference only in "Switching a directory to symlink" for "dpkg-
> maintscript-helper dir_to_symlink ...". Your argument doesn't make sense.
I stand corrected. There is no ownership checking in that code path.
However, there is version checking code.
dpkg --compare-versions -- "$2" le-nl "$LASTVERSION"
That "$2" is the version of the old debian-reference-de. If there is one
installed, the dpkg-maintscript-helper will move the symlink and there
is docs.dpkg-backup. When debian-reference-de is not installed, the
version is empty and the "-nl" suffix renders the comparison false
skipping the action.
> > > $ sudo apt-get -y -f install
> ...
> > > Unpacking debian-reference-common (2.126) over (2.100) ...
> > > Setting up debian-reference-common (2.126) ...
> >
> > This is when the link really got converted into a directory.
>
> No. It was done by debian-reference-de.preinst as shown in the above and
> debian-reference-common.preinst here becomes NOP since there is no symlink.
We need to add precision here. What you describe is what happens when
debian-reference-de is initially installed. It can also happen the other
way round when it is not.
So here is a slightly improved reproducer.
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/sid/ /etc/apt/sources.list && apt-get update && apt-get
download debian-reference-de' --chrooted-customize-hook='DPKG_DEBUG=1 dpkg
--unpack --auto-deconfigure *.deb' --chrooted-customize-hook='ls -la
/usr/share/doc/debian-reference-common/ && apt-get -y -f install && dpkg
--verify'
I split the unpacking step into a separate hook for you to clearly see
how they're disconnected. I also added DPKG_DEBUG to let us see that the
maintscript helper indeed is being run and copied your ls -l invocation
to observe its effects. You will see that in that reproducer, the
symlink is not converted and encourage you to run it locally so you can
play with it in a fresh and clean environment rather than operating on
your host system and therefore skip including any output here.
mmdebstrap operates as a regular user account and given that the target
is /dev/null it does not write any files outside $TMPDIR and cleans up
behind itself. A useful trick for interactive examination is
--chrooted-customize-hook=bash as that results in you being dropped into
a shell prompt until you exit it.
If you change --include=debian-reference-common to
--include=debian-reference-de, you shall observe that at that point the
"le-nl" comparison becomes successful and therefore, the symlink is
converted during debian-reference-de.preinst and thus the problem is no
longer observable.
There are other corner cases that should be broken if you initially
start with bookworm's debian-reference-de installed. Consider:
* unpack sid debian-reference-de (renames the docs link)
* purge debian-reference-de (deletes the docs.dpkg-backup link)
* dpkg --verify now complains about the docs link owned by
debian-reference-common going missing
Helmut
