Package: debian-reference-de,debian-reference-en,debian-reference-es,debian-reference-fr,debian-reference-id,debian-reference-it,debian-reference-ja,debian-reference-pt,debian-reference-pt-br,debian-reference-zh-cn,debian-reference-zh-tw
Version: 2.125
Severity: serious
User: debian-qa@lists.debian.org
Usertags: fileconflict
Control: affects -1 + debian-reference-common
The debian-reference packages have a tricky undeclared file conflict
that may break bookworm to trixie upgrades. In bookworm, debian-reference-common contains a symlink /usr/share/doc/debian-reference-common/docs pointing to ../../debian-reference whereas the debian-references-* packages in
trixie install the same location as a directory. On the face of it, this
is an undeclared file conflict. Really though, a bad unpack order can
cause the unpack of the trixie files to be redirected and then go
missing as this is a symlink to directory conversion moving between
packages. The debian-refefence-* packages really need to prevent
concurrent unpack with bookworm's debian-reference-common. Breaks and Replaces is not sufficient here. I think the options basically are using Conflicts or upgrading the versioned dependency on
debian-reference-common to a Pre-Depends (requires consultation with d-devel). The latter option is a larger hammer and prevents a weird
corner case that is not covered by Conflicts.
Helmut
Hi,
Following up on my previous post.
How about adding simpler versioned depends (no pre-depends) with pre-rm script?
I am talking about tricks using the "dpkg-maintscript-helper symlink_to_dir ..."
command. Any thought?
Osamu
On Thu, 2025-04-17 at 20:40 +0900, Osamu Aoki wrote:
Hi,
I now see this as a bug. I think this was caused by my post-bookworm change
in
debian-reference (2.109) on Mon, 18 Dec 2023.
If I remember correctly, the intent of this change was to move all HTML/PDF/Plain_Text document to a path under /usr/share/doc/ for better policy
compliance.
This regression was partly addressed in debian-reference (2.114) by closing #1063590 on Sat, 10 Feb 2024. What is reported is the remaining issue.
So the question is the best known method to mitigate potential upgrade problem.
I now understand "adding Conflicts or upgrading the versioned dependency on debian-reference-common to a Pre-Depends" is one way.
Before doing it, I would like to know the best established method.
How about adding simpler versioned depends (no pre-depends) with pre-rm script?
Isn't it simpler?
Or is there any other simpler and cleaner established solution. (A pointer to
a
package using such trics will be good for me.)
Any suggestion?
Osamu
On Sun, 2025-04-13 at 16:08 +0200, textshell@uchuujin.de wrote:
I belive debian wants to provide its documentation as packages in stable releases.
But currently debian-reference is scheduled for auto removal on 2025-04-15
(which this mail bumps a bit into the future).
Maybe "nobody" is aware of this?
Anyone up to taking a look at this?
On Mon, 17 Mar 2025 08:14:02 +0100 Helmut Grohne <helmut@subdivi.de> wrote:
Package: debian-reference-de,debian-reference-en,debian-reference- es,debian- reference-fr,debian-reference-id,debian-reference-it,debian-reference- ja,debian-reference-pt,debian-reference-pt-br,debian-reference-zh- cn,debian-
reference-zh-tw
Version: 2.125
Severity: serious
User: debian-qa@lists.debian.org
Usertags: fileconflict
Control: affects -1 + debian-reference-common
The debian-reference packages have a tricky undeclared file conflict that may break bookworm to trixie upgrades. In bookworm, debian-reference-common contains a symlink /usr/share/doc/debian-reference-common/docs pointing to ../../debian-reference whereas the debian-references-* packages in trixie install the same location as a directory. On the face of it, this
is an undeclared file conflict. Really though, a bad unpack order can cause the unpack of the trixie files to be redirected and then go missing as this is a symlink to directory conversion moving between packages. The debian-refefence-* packages really need to prevent concurrent unpack with bookworm's debian-reference-common. Breaks and Replaces is not sufficient here. I think the options basically are using
Conflicts or upgrading the versioned dependency on debian-reference-common to a Pre-Depends (requires consultation with d-devel). The latter option is a larger hammer and prevents a weird corner case that is not covered by Conflicts.
Helmut
As I assessed, since this bug hits user using testing only, this is not serious
bug per Policy. Excuse me for my pedantic reasoning.
Rationale: There is no error seen by the official testing of Debian package transition checks.
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.
Control: severity -1 serious
On Thu, Apr 17, 2025 at 10:41:08PM +0900, Osamu Aoki wrote:
As I assessed, since this bug hits user using testing only, this is not serious
bug per Policy. Excuse me for my pedantic reasoning.
As I reproduced the problem in bookworm to trixie upgrades with 2.126,
the reasoning for downgrading to important no longer applies and I am upgrading it back to serious.
Rationale: There is no error seen by the official testing of Debian package transition checks.
I asked the release team how to best integrate conflict checking into
testing migration checks and the answer was to use automated rc bugs. Therefore, please consider this rc bug an official testing transition
check. It would also be possible to feed conflict checking directly into britney2, but we opted to use rc bugs here.
The safe way to fix this problem is upgrading the dependencies to
Pre-Depends and given that debian-reference-$LANG has no reverse dependencies, that has a low chance of causing further problems while at
the same time reliably fixing the problem at hand by forcing correct
ordering of the symlink transition.
Helmut
| 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)
Hi Osamu,
On Sun, Apr 27, 2025 at 07:01:44PM +0900, Osamu Aoki wrote:
Since you seem to be very knowlegeable, I have a question:
Isn't the APT system smart enough to run all preinst scripts of all downloaded
packages?
apt is only half the story. In principle, you may perform upgrades with dselect or dpkg directly. It just so happens that everyone uses apt. Now
apt instructs dpkg to do its thing, but subtle changes in dependencies
may instruct apt to order its instructions differently. Ultimately, what needs to happen here is making valid dpkg interactions work.
Generally, dpkg may choose to unpack debian-reference-$LANG before
unpacking debian-reference-common even though it may only configure debian-reference-$LANG after having configured debian-reference-common.
In particular, debian-reference-$LANG may be unpacked before running debian-reference-common.preinst. I see how that is not desirable. We
would like to tell apt and dpkg to always unpack debian-reference-common before unpacking debian-reference-$LANG. The way to do that is declaring suitable Conflicts or better Pre-Depends.
I argue that debian-reference-$LANG should really declare:
Depends: debian-reference-common (= ${source:Version})
Pre-Depends: debian-reference-common (>= 2.109~)
Pre-Depends are also required if the preinst script depends on the named package. It is best to avoid this situation if possible.
Pre-Depends should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress.
You should not specify a Pre-Depends entry for a package before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached. See Dependencies.
It took me some time to set up my private apt repository to test next upload in
advance without using the real Debian repository ;-) That leads me to the following conclusion.
1. There were a bug in version 2.125
2. Your testing script lead me to realize the bug.
3. I see no issue here on 2.126 packages. (See below log)
4. My fix use no pre-depends following policy guidance (See the bottom)
Can you show me actual failure log you observed on your system with the current
2.126 packages. Until then, let me downgrade this bug
$ apt-get download debian-reference-de
Get:1 https://osamuaoki.github.io/debian sid/main amd64 debian-reference-de all
2.126 [1,925 kB]
Fetched 1,925 kB in 1s (2,714 kB/s)
osamu@goofy:~/salsa/debian-reference/test 00:11:17 ↵
$ ls -l
total 1892
-rw-r--r-- 1 osamu osamu 1925248 Apr 28 23:23 debian-reference-de_2.126_all.deb
osamu@goofy:~/salsa/debian-reference/test 00:11:28 ↵
$ sudo dpkg --unpack --auto-deconfigure debian-reference-de_2.126_all.deb (Reading database ... 636494 files and directories currently installed.) Preparing to unpack debian-reference-de_2.126_all.deb ...
Unpacking debian-reference-de (2.126) over (2.100) ...
Processing triggers for doc-base (0.11.1) ...
Processing 1 changed doc-base file... osamu@goofy:~/salsa/debian-reference/test 00:13:12 ↵
$ sudo apt-get -y -f install
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
The following packages will be upgraded:
debian-reference-common
1 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
1 not fully installed or removed.
Need to get 0 B/38.1 kB of archives.
After this operation, 7,168 B of additional disk space will be used.
N: Make snapshot (system snapshot mode): BASE=/ DEST=/disk_volume/main/@rootfs-snapshots TIME=2025-04-28T15:13:54+00:00 TYPE=pre
Create a snapshot of '/' in '/disk_volume/main/@rootfs-snapshots/2025-04- 28T15:13:54+00:00.pre'
apt-listchanges: Reading changelogs...
(Reading database ... 636493 files and directories currently installed.) Preparing to unpack .../debian-reference-common_2.126_all.deb ...
Unpacking debian-reference-common (2.126) over (2.100) ...
Setting up debian-reference-common (2.126) ...
Setting up debian-reference-de (2.126) ...
Processing triggers for mailcap (3.70+nmu1) ...
Processing triggers for desktop-file-utils (0.26-1) ...
Processing triggers for gnome-menus (3.36.0-1.1) ...
Processing triggers for man-db (2.11.2-2) ...
N: Make snapshot (system snapshot mode): BASE=/ DEST=/disk_volume/main/@rootfs-snapshots TIME=2025-04-28T15:13:57+00:00 TYPE=post
Create a snapshot of '/' in '/disk_volume/main/@rootfs-snapshots/2025-04- 28T15:13:57+00:00.post'
Scanning processes...
Scanning processor microcode...
Scanning linux images...
Running kernel seems to be up-to-date.
The processor microcode seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host. osamu@goofy:~/salsa/debian-reference/test 00:13:59 ↵
$
```
I see symlink /usr/share/doc/debian-reference-common/doc is properly changed to
directory ;-) No more issue seen here.
In this section, Policy states:
Pre-Depends are also required if the preinst script depends on the named package. It is best to avoid this situation if possible.
Pre-Depends should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress.
You should not specify a Pre-Depends entry for a package before this has been
discussed on the debian-devel mailing list and a consensus about doing that has been reached. See Dependencies.
In my test, the updated package seems to work without pre-depends, I should avoid using it, I think.
I still see APT warning in your updated test install log.
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.
"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.
Unpacking debian-reference-de (2.126) ...
It looks like it failed since preinst script was skipped when it really meant to
be executed.
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 ↵
I see "own" reference only in "Switching a directory to symlink" for "dpkg- maintscript-helper dir_to_symlink ...". Your argument doesn't make sense.
...$ 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.
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.
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
diff --git a/debian/all.maintscript-in b/debian/all.maintscript-in
index bf02b4f9..ab378d0a 100644
--- a/debian/all.maintscript-in
+++ b/debian/all.maintscript-in
@@ -1 +1 @@
-symlink_to_dir /usr/share/doc/debian-reference-common/docs ../../debian-reference 2.126~ debian-reference-@@
+symlink_to_dir /usr/share/doc/debian-reference-common/docs ../../debian-reference 2.127~ debian-reference-common
Hi,
It looks like
diff --git a/debian/all.maintscript-in b/debian/all.maintscript-in
index bf02b4f9..ab378d0a 100644
--- a/debian/all.maintscript-in
+++ b/debian/all.maintscript-in
@@ -1 +1 @@
-symlink_to_dir /usr/share/doc/debian-reference-common/docs ../../debian-reference 2.126~ debian-reference-@@
+symlink_to_dir /usr/share/doc/debian-reference-common/docs ../../debian-reference 2.127~ debian-reference-common
with version bumps on d/control etc. may work. I will test it tomorrow.
Regards,
Osamu
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 483 |
Nodes: | 16 (2 / 14) |
Uptime: | 196:40:17 |
Calls: | 9,601 |
Calls today: | 2 |
Files: | 13,682 |
Messages: | 6,152,226 |