[Piuparts-devel] Bug#1065531 closed by Julian Andres Klode <jak at debian.org> (Re: Bug#1065531: apt forced libexpat1 to be removed before python3.11-minimal)

Helmut Grohne helmut at subdivi.de
Wed Mar 6 09:35:49 GMT 2024


Hi Julian,

On Wed, Mar 06, 2024 at 09:12:06AM +0000, Debian Bug Tracking System wrote:
> Control: reassign -1 libexpat164

There is no libexpat1t64. expat is not affected by time64.

> On Wed, Mar 06, 2024 at 12:11:30PM +0500, Andrey Rahmatullin wrote:
> > Package: apt,python3.11-minimal
> > Severity: normal
> > 
> > Control: affects -1 python3-scrapy
> > 
> > During piuparts testing of python3-scrapy piuparts asked apt to remove packages
> > including python3* and libexpat1, and libexpat1 was removed before e.g.
> > python3.11-minimal which depends on it, with dpkg printing a warning about this
> > fact. But as prerm of python3.11-minimal needs libexpat1, prerm and the apt
> > transaction failed with "/usr/bin/python3: error while loading shared
> > libraries: libexpat.so.1: cannot open shared object file". The full log is
> > currently available at
> > https://piuparts.debian.org/sid/fail/python3-scrapy_2.11.1-1.log and I'm also
> > attaching it. The relevant part is the last one.
> > 
> > There are several additional things to note:
> > 
> > 1. "python3.11-minimal depends on libexpat1" is not the only dependency problem
> > reported for the transaction, there are several other problems reported later,
> > all involving python3{,.11} subpackages.
> > 2. This happened during the t64 transition, involved versions of src:expat and
> > src:python3-defaults are older than that while src:python3.11 (= 3.11.8-2) is
> > related to it.
> > 3. piuparts asked apt to remove (among other packages) libssl3t64 and install
> > libssl3:amd64=3.1.5-1, but libssl3* aren't related to libexpat1,
> > python3.11-minimal also doesn't depend on them.
> 
> I'm closing this bug as it's not a valid use case to install libssl3
> after having migrated to libssl3t64. Please refrain from filing similar
> bugs, or any dependency issues at least for another week.

I am inclined to agree that installing libssl3 is not a good idea.
However, this is piuparts doing it. Then maybe this is a bug in
piuparts? Why do we test installing libssl3 when that is entirely
unsupported?

> And there's not much point assigning them to apt, we're not going to fix
> them there.

It was me who suggested assigning to apt. Let me explain why. According
to Debian policy section 6.5, a prerm script can rely on its Depends
being at least Half-Installed. Evidently, apt chose to remove libexpat1
before python3.11 though for reasons beyond my comprehension. I tried to
locally reproduce said failure without success (but we still have the
log). Generally speaking, there would have been a more reasonable
solution to the task at hand. apt could have chosen to first remove all
requested packages but libssl3t64 in a suitable order and then as a
final step remove libssl3t64 before installing libssl3. This makes it
clear that apt went for a suboptimal solution that needlessly violates
policy.

I guess this is a more general problem and python3+expat is just an
instance of a more recurring pattern. As such, it may still be worth
fixing even though the fix will not help with the time64 transition.

Does this argument make you reconsider the closure of this bug?

Helmut




More information about the Piuparts-devel mailing list