Le 2023-12-09 à 17 h 29, tony mancill a écrit :
On Sat, Dec 09, 2023 at 04:39:35PM -0500, Jérôme Charaoui wrote:
On Mon, 30 Oct 2023 09:37:34 +0100 Andreas Beckmann <a...@debian.org> wrote:
during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
From the attached log (scroll to the bottom...):
Preparing to unpack .../libtakari-polyglot-groovy-java_0.4.11-2_all.deb ...
Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ...
dpkg: error processing archive
/var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb
(--unpack):
trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which is
also in package libtakari-polyglot-maven-java 0.4.11-1
Errors were encountered while processing:
/var/cache/apt/archives/libtakari-polyglot-groovy-java_0.4.11-2_all.deb
Thanks for the heads up.
I'm not sure what's happening here: polyglot-groovy-0.4.11.jar was indeed
split away from "libtakari-polyglot-maven-java" and into
"libtakari-polyglot-groovy-java", however the new version of
"libtakari-polyglot-maven-java" does *not* depend on/recommend
"libtakari-polyglot-groovy-java".
So I'm unsure why "libtakari-polyglot-groovy-java" is being installed in the
first place, during the piuparts upgrade. It's not present in testing, and
it has currently zero reverse-dependencies.
I did my own testing and on a bare system with
"libtakari-polyglot-maven-java" installed, upgrading to sid does not include
an installation of "libtakari-polyglot-groovy-java".
Any idea what's going on?
Hi Jérôme,
I believe you're correct that in the normal upgrade case, this is
unlikely to occur. Here's the test case I ran instead a clean trixie
chroot:
1. Install libtakari-polyglot-maven-java (0.4.11-1)
2. Update sources.list to unstable and then apt-get update
3. apt-get -y install libtakari-polyglot-groovy-java
Step (3) will upgrade libtakari-polyglot-maven-java to 0.4.11-2 *before*
installing libtakari-polyglot-groovy-java, so there's no problem.
However, the issue can occur when using dpkg directly, or some other
factor influences the ordering such that libtakari-polyglot-groovy-java
is installed *before* libtakari-polyglot-maven-java is upgraded.
For example:
1. Install libtakari-polyglot-maven-java (0.4.11-1)
2. wget
http://ftp.us.debian.org/debian/pool/main/t/takari-polyglot-maven/libtakari-polyglot-groovy-java_0.4.11-2_all.deb
3. dpkg -i libtakari-polyglot-groovy-java_0.4.11-2_all.deb
Preparing to unpack libtakari-polyglot-groovy-java_0.4.11-2_all.deb ...
Unpacking libtakari-polyglot-groovy-java (0.4.11-2) ...
dpkg: error processing archive libtakari-polyglot-groovy-java_0.4.11-2_all.deb
(--install):
trying to overwrite '/usr/share/java/polyglot-groovy-0.4.11.jar', which is
also in package libtakari-polyglot-maven-java 0.4.11-1
Errors were encountered while processing:
libtakari-polyglot-groovy-java_0.4.11-2_all.deb
This is the reason that the relationship needs to be explicit.
I'm not 100% certain, but perhaps we can get away with only adding a
versioned depends on libtakari-polyglot-maven-java (>= 0.4.11-2) to the
libtakari-polyglot-groovy-java package. The problem as I see it is that
the current unversioned Depends can be satisfied by any version of
libtakari-polyglot-maven-java, including older versions with the file
conflict. Requiring the newer libtakari-polyglot-maven-java would
prevent this.
Ok what I think I'll do is to add: "Breaks:
libtakari-polyglot-maven-java (<< 0.4.11-2)" to
libtakari-polyglot-groovy-java. I think that's more explicit than a
versioned depends, and should prevent any instances of users
accidentally having wrong versions of the two packages.
-- Jérôme
