Bug#887863: Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Guillem Jover]

Hi!

On Sun, 2018-01-21 at 17:13:38 +0200, Niko Tyni wrote:
> On Sun, Jan 21, 2018 at 05:32:01AM +0100, Guillem Jover wrote:
> > On Sun, 2018-01-21 at 02:59:53 +0100, Andreas Beckmann wrote:
> > > Even if python is going to get fixed, this probably won't help
> > > libglib2.0-dev (which drops the python dependency in buster), therefore
> > > it will need to add the dummy empty prerm to mitigate this issue.
> > 
> > I don't see why this would be needed. If python gets fixed to use
> > Pre-Depends, then it does not matter whether libglib2.0-dev stops
> > depending on it, as python should then be always usable even when
> > just unpacked.
> 
> stretch# apt --no-install-recommends install glib2.0-dev
> [...]
> stretch# dpkg --unpack libexpat1_2.2.5-3_amd64.deb # from sid
> [...]
> stretch# dpkg --unpack libglib2.0-dev_2.54.3-1_amd64.deb # from sid
> /usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not 
> found (required by /lib/x86_64-linux-gnu/libexpat.so.1)
> dpkg: warning: subprocess old pre-removal script returned error exit status 1
> dpkg: trying script from the new package instead ...
> dpkg: error processing archive libglib2.0-dev_2.54.3-1_amd64.deb (--unpack):
>  there is no script in the new version of the package - giving up
> /usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not 
> found (required by /lib/x86_64-linux-gnu/libexpat.so.1)
> dpkg: error while cleaning up:
>  subprocess installed post-installation script returned error exit status 1
> 
> No python3 change in sid/buster is going to prevent this afaics?

Ah sorry, you are exactly right. Good think this is even worked around
now in unstable anyway. :)

Thanks,
Guillem

Bug#887863: Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Niko Tyni]

On Sun, Jan 21, 2018 at 05:32:01AM +0100, Guillem Jover wrote:
> On Sun, 2018-01-21 at 02:59:53 +0100, Andreas Beckmann wrote:
> > Control: clone -1 -2
> > Control: retitle -2 libglib2.0-dev: needs dummy empty prerm
> > Control: reassign -2 libglib2.0-dev 2.54.2-1
> > 
> > >> On Sat, Jan 20, 2018 at 05:07:30PM +0100, Andreas Beckmann wrote:>>> For 
> > >> now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this
> > Even if python is going to get fixed, this probably won't help
> > libglib2.0-dev (which drops the python dependency in buster), therefore
> > it will need to add the dummy empty prerm to mitigate this issue.
> 
> I don't see why this would be needed. If python gets fixed to use
> Pre-Depends, then it does not matter whether libglib2.0-dev stops
> depending on it, as python should then be always usable even when
> just unpacked.

stretch# apt --no-install-recommends install glib2.0-dev
[...]
stretch# dpkg --unpack libexpat1_2.2.5-3_amd64.deb # from sid
[...]
stretch# dpkg --unpack libglib2.0-dev_2.54.3-1_amd64.deb # from sid
/usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not 
found (required by /lib/x86_64-linux-gnu/libexpat.so.1)
dpkg: warning: subprocess old pre-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg: error processing archive libglib2.0-dev_2.54.3-1_amd64.deb (--unpack):
 there is no script in the new version of the package - giving up
/usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not 
found (required by /lib/x86_64-linux-gnu/libexpat.so.1)
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 1

No python3 change in sid/buster is going to prevent this afaics?
-- 
Niko Tyni   nt...@debian.org

Bug#887863: Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Guillem Jover]

On Sun, 2018-01-21 at 02:59:53 +0100, Andreas Beckmann wrote:
> Control: clone -1 -2
> Control: retitle -2 libglib2.0-dev: needs dummy empty prerm
> Control: reassign -2 libglib2.0-dev 2.54.2-1
> 
> >> On Sat, Jan 20, 2018 at 05:07:30PM +0100, Andreas Beckmann wrote:>>> For 
> >> now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this
> Even if python is going to get fixed, this probably won't help
> libglib2.0-dev (which drops the python dependency in buster), therefore
> it will need to add the dummy empty prerm to mitigate this issue.

I don't see why this would be needed. If python gets fixed to use
Pre-Depends, then it does not matter whether libglib2.0-dev stops
depending on it, as python should then be always usable even when
just unpacked.

Thanks,
Guillem

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Andreas Beckmann]

Control: clone -1 -2
Control: retitle -2 libglib2.0-dev: needs dummy empty prerm
Control: reassign -2 libglib2.0-dev 2.54.2-1

>> On Sat, Jan 20, 2018 at 05:07:30PM +0100, Andreas Beckmann wrote:>>> For 
>> now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this
Even if python is going to get fixed, this probably won't help
libglib2.0-dev (which drops the python dependency in buster), therefore
it will need to add the dummy empty prerm to mitigate this issue.


Andreas

Processed: Re: Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Debian Bug Tracking System]

Processing control commands:

> clone -1 -2
Bug #887629 [python2.7-minimal,python3.6-minimal,debhelper] python: Wants to be 
used like Essential:yes but does not follow its requirements
Bug 887629 cloned as bug 887863
> retitle -2 libglib2.0-dev: needs dummy empty prerm
Bug #887863 [python2.7-minimal,python3.6-minimal,debhelper] python: Wants to be 
used like Essential:yes but does not follow its requirements
Changed Bug title to 'libglib2.0-dev: needs dummy empty prerm' from 'python: 
Wants to be used like Essential:yes but does not follow its requirements'.
> reassign -2 libglib2.0-dev 2.54.2-1
Bug #887863 [python2.7-minimal,python3.6-minimal,debhelper] libglib2.0-dev: 
needs dummy empty prerm
Bug reassigned from package 'python2.7-minimal,python3.6-minimal,debhelper' to 
'libglib2.0-dev'.
Ignoring request to alter found versions of bug #887863 to the same values 
previously set
Ignoring request to alter fixed versions of bug #887863 to the same values 
previously set
Bug #887863 [libglib2.0-dev] libglib2.0-dev: needs dummy empty prerm
Marked as found in versions glib2.0/2.54.2-1.

-- 
887629: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887629
887863: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887863
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Guillem Jover]

Control: reassign -1 python2.7-minimal,python3.6-minimal,debhelper
Control: retitle -1 python: Wants to be used like Essential:yes but does not 
follow its requirements
Control: affects -1 - libc6 libexpat1
Control: affects -1 + libglib2.0-dev

Hi!

On Sat, 2018-01-20 at 23:19:30 +0200, Niko Tyni wrote:
> On Sat, Jan 20, 2018 at 05:07:30PM +0100, Andreas Beckmann wrote:
> > For now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this
> > error starts to show up elsewhere (e.g. in a package where both old and
> > new prerm use python3), probably adding the Pre-Depends to libexpat1
> > would be the general solution.
> 
> FWIW, I have the feeling that having libexpat1 Pre-Depend:libc6 would
> be a wrong place to fix this longer-term, though it might be a viable
> workaround for now. I fear that this will pop up with zlib1g (another
> dependency of python3.5-minimal in stretch) next as soon as it gets built
> against a newer glibc version. And having special handling in libexpat1
> and zlib1g because they happen to be dependencies of python3.x-minimal
> seems wrong.

Yes.

> The core problem here is python3 usage in 'prerm upgrade'. Non-essential
> packages are not generally safe to use at that point. AFAICS, if
> python3.x-minimal is intended to be usable in 'prerm upgrade', it
> needs to follow the same rules as essential packages: "must supply
> all of their core functionality even when unconfigured" (policy 3.8).
> In practice I think that means it must Pre-Depend on all the libraries
> it links against, (so libexpat1 and zlib1g in addition to the current
> pre-dependency on libc.)

Exactly right. :) BTW this would require a discussion on debian-devel,
even though I guess it might not be controversial.

> [I don't know if even that is enough or if apt/dpkg give special treatment
> to packages tagged Essential:yes in this context.]

dpkg only takes Essential:yes into account on removal, when showing
its scary prompt; and when deconfiguring a package, to refuse the
action. AFAIR apt uses Essential:yes as things that need to
be installed (if they are not), for its own scary prompt, and to
prioritize its installation at the beginning of the transaction.

> Now, as we can't change python3 in stretch anymore, we can either push
> this down the chain in sid/buster and modify new libexpat1 and zlib1g to
> pre-depend on libc as a workaround, or we have to add fallback 'new-prerm
> failed-upgrade' handling to the packages whose 'prerm upgrade' in stretch
> is using python3.

I don't think this needs to be changed in stretch anyway? The new
dependencies on the newer libc are coming from sid/buster, so fixing
that should be enough, AFAICS (but I've not looked very hard :).

> I see the py3clean invocation is generated by dh_python3 so this is
> probably going to be much wider issue than just libglib2.0-dev...

I'm also assigning to debhelper, in case this needs mitigations there
too. Feel free to sort this out between yourselves, by reassigning,
cloning or whatever. ;)

Thanks,
Guillem

Processed: Re: Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 python2.7-minimal,python3.6-minimal,debhelper
Bug #887629 [apt,dpkg] libc6: bad upgrade path: libexpat1 unpacked and python3 
called before libc6 unpacked
Bug reassigned from package 'apt,dpkg' to 
'python2.7-minimal,python3.6-minimal,debhelper'.
Ignoring request to alter found versions of bug #887629 to the same values 
previously set
Ignoring request to alter fixed versions of bug #887629 to the same values 
previously set
> retitle -1 python: Wants to be used like Essential:yes but does not follow 
> its requirements
Bug #887629 [python2.7-minimal,python3.6-minimal,debhelper] libc6: bad upgrade 
path: libexpat1 unpacked and python3 called before libc6 unpacked
Changed Bug title to 'python: Wants to be used like Essential:yes but does not 
follow its requirements' from 'libc6: bad upgrade path: libexpat1 unpacked and 
python3 called before libc6 unpacked'.
> affects -1 - libc6 libexpat1
Bug #887629 [python2.7-minimal,python3.6-minimal,debhelper] python: Wants to be 
used like Essential:yes but does not follow its requirements
Removed indication that 887629 affects libc6 and libexpat1
> affects -1 + libglib2.0-dev
Bug #887629 [python2.7-minimal,python3.6-minimal,debhelper] python: Wants to be 
used like Essential:yes but does not follow its requirements
Added indication that 887629 affects libglib2.0-dev

-- 
887629: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887629
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Guillem Jover]

Hi!

On Thu, 2018-01-18 at 21:45:51 +0100, Aurelien Jarno wrote:
> On 2018-01-18 20:38, Julian Andres Klode wrote:
> > On Thu, Jan 18, 2018 at 06:41:52PM +0100, Aurelien Jarno wrote:
> > > This failure is normal given libexpat1 requires the new libc which has
> > > not been unpacked yet.
> > 
> > Yeah, well, it needs to Pre-Depend on it then I guess, if it's being used
> > in preinst actions. The thing is that Depends only after postinst ordering,
> > not unpack ordering.
> 
> Well it's not the preinst script, but the prerm script. The problem is
> unpacking libexpat1 before libc6 breaks libexpat1 and not usable
> anymore.

Depends only applies at configure time, not unpack time anyway. In
addition in this case dpkg does not even know there's such dependency
because the new package does not depend on python any longer (and dpkg
only tests the dependencies of the new version not the old one).

> From what I understand from the debian-policy, a prerm script might
> consider that all the dependencies have been at least unpacked when
> called:
> 
> | "The package whose prerm is being called will be at least
> | “Half-Installed”. All package dependencies will at least be
> | “Half-Installed” and will have previously been configured and not
> | removed. If there was no error, all dependencies will at least be
> | “Unpacked”, but these actions may be called in various error
> | states where dependencies are only “Half-Installed” due to a
> | partial upgrade.

First, notice that half-installed is one state lower than unpacked. In
addition when it says that "All package dependencies will at least be
“Half-Installed” and will have previously been configured and not
removed.", this means that they will have been fully configured before
on any version, but not the depended-on version (if there's such
dependency now).

Thanks,
Guillem

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Niko Tyni]

On Sat, Jan 20, 2018 at 05:07:30PM +0100, Andreas Beckmann wrote:

> For now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this
> error starts to show up elsewhere (e.g. in a package where both old and
> new prerm use python3), probably adding the Pre-Depends to libexpat1
> would be the general solution.

FWIW, I have the feeling that having libexpat1 Pre-Depend:libc6 would
be a wrong place to fix this longer-term, though it might be a viable
workaround for now. I fear that this will pop up with zlib1g (another
dependency of python3.5-minimal in stretch) next as soon as it gets built
against a newer glibc version. And having special handling in libexpat1
and zlib1g because they happen to be dependencies of python3.x-minimal
seems wrong.

The core problem here is python3 usage in 'prerm upgrade'. Non-essential
packages are not generally safe to use at that point. AFAICS, if
python3.x-minimal is intended to be usable in 'prerm upgrade', it
needs to follow the same rules as essential packages: "must supply
all of their core functionality even when unconfigured" (policy 3.8).
In practice I think that means it must Pre-Depend on all the libraries
it links against, (so libexpat1 and zlib1g in addition to the current
pre-dependency on libc.)

[I don't know if even that is enough or if apt/dpkg give special treatment
to packages tagged Essential:yes in this context.]

Now, as we can't change python3 in stretch anymore, we can either push
this down the chain in sid/buster and modify new libexpat1 and zlib1g to
pre-depend on libc as a workaround, or we have to add fallback 'new-prerm
failed-upgrade' handling to the packages whose 'prerm upgrade' in stretch
is using python3.

I see the py3clean invocation is generated by dh_python3 so this is
probably going to be much wider issue than just libglib2.0-dev...

Just my two cents,
-- 
Niko Tyni   nt...@debian.org

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Andreas Beckmann]

On 2018-01-18 23:59, David Kalnischkies wrote:
> Hi,
> 
> On Thu, Jan 18, 2018 at 09:45:51PM +0100, Aurelien Jarno wrote:
> [...]
>   Preparing to unpack .../3-libglib2.0-dev_2.54.3-1_i386.deb ...
>   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' 
> not found (required by /lib/i386-linux-gnu/libexpat.so.1)
>   dpkg: warning: subprocess old pre-removal script returned error exit 
> status 1
>   dpkg: trying script from the new package instead ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-wfemKS/3-libglib2.0-dev_2.54.3-1_i386.deb 
> (--unpack):
>there is no script in the new version of the package - giving up
>   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' 
> not found (required by /lib/i386-linux-gnu/libexpat.so.1)

 This failure is normal given libexpat1 requires the new libc which has
 not been unpacked yet.
>>>
>>> Yeah, well, it needs to Pre-Depend on it then I guess, if it's being used
>>> in preinst actions. The thing is that Depends only after postinst ordering,
>>> not unpack ordering.
>>
>> Well it's not the preinst script, but the prerm script. The problem is
>> unpacking libexpat1 before libc6 breaks libexpat1 and not usable
>> anymore.
> 
> prerm is the very first script being called (see §6.6) and usually it is
> the script of the version installed (only in error cases the script from
> the version being upgraded to will be tried as detailed in the dpkg
> messages) so I would argue that the dependencies (maybe) satisfied are
> the dependencies of the installed version, not the one being installed
> (argueably the dependency set of v1 and v2 could conflict with each
> other, so if dependencies of v2 would be satisfied that means v1 script
> would be bound to explode). But thats perhaps just the fear talking as
> going with dependencies of v2 would probably result in a lot of hard
> coding problems for apt & dpkg (and other low package managers).
> 
> In any case, the unpack of these packages is in the same dpkg call, so
> if dpkg would have wanted it could have reordered them & apt has no idea
> about maintainerscript in general, so I would say this isn't an apt bug.
> 
> (Althrough, if we decide on v2, I guess apt needs to change anyhow as
> that same call thing might be just dumb luck in this case. Not even sure
> if v1 is in any way "guaranteed" to be perfectly honest…)
> 
> Can't stop the feeling that we had issues with python begin called from
> prerm before and the general advice was: "don't – stick to essential".

I tested a bit more to find adding which Pre-Depends would solve the
issue *without* adding a dummy empty prerm to libglib2.0-dev:

libglib2.0-dev: Pre-Depends: libexpat1
OR
libexpat1: Pre-Depends: libc6 (>= 2.25)

The following does not help:

libglib2.0-dev: Pre-Depends: python3:any


For now, I'd suggest the dummy empty libglib2.0-dev.prerm, but if this
error starts to show up elsewhere (e.g. in a package where both old and
new prerm use python3), probably adding the Pre-Depends to libexpat1
would be the general solution.


Andreas

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Andreas Beckmann]

On 2018-01-18 21:45, Aurelien Jarno wrote:
 [...]
   Preparing to unpack .../3-libglib2.0-dev_2.54.3-1_i386.deb ...
   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' 
 not found (required by /lib/i386-linux-gnu/libexpat.so.1)
   dpkg: warning: subprocess old pre-removal script returned error exit 
 status 1
   dpkg: trying script from the new package instead ...
   dpkg: error processing archive 
 /tmp/apt-dpkg-install-wfemKS/3-libglib2.0-dev_2.54.3-1_i386.deb (--unpack):
there is no script in the new version of the package - giving up
   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' 
 not found (required by /lib/i386-linux-gnu/libexpat.so.1)
>>>
>>> This failure is normal given libexpat1 requires the new libc which has
>>> not been unpacked yet.
>>
>> Yeah, well, it needs to Pre-Depend on it then I guess, if it's being used
>> in preinst actions. The thing is that Depends only after postinst ordering,
>> not unpack ordering.
> 
> Well it's not the preinst script, but the prerm script. The problem is
> unpacking libexpat1 before libc6 breaks libexpat1 and not usable
> anymore.

This particular case could be fixed by adding an empty dummy prerm to
libglib2.0-dev s.t. the script from the new package exists and does not
fail. But that wouldn't work if it would still use python ...


Andreas

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[David Kalnischkies]

Hi,

On Thu, Jan 18, 2018 at 09:45:51PM +0100, Aurelien Jarno wrote:
> > > > [...]
> > > >   Preparing to unpack .../3-libglib2.0-dev_2.54.3-1_i386.deb ...
> > > >   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' 
> > > > not found (required by /lib/i386-linux-gnu/libexpat.so.1)
> > > >   dpkg: warning: subprocess old pre-removal script returned error exit 
> > > > status 1
> > > >   dpkg: trying script from the new package instead ...
> > > >   dpkg: error processing archive 
> > > > /tmp/apt-dpkg-install-wfemKS/3-libglib2.0-dev_2.54.3-1_i386.deb 
> > > > (--unpack):
> > > >there is no script in the new version of the package - giving up
> > > >   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' 
> > > > not found (required by /lib/i386-linux-gnu/libexpat.so.1)
> > > 
> > > This failure is normal given libexpat1 requires the new libc which has
> > > not been unpacked yet.
> > 
> > Yeah, well, it needs to Pre-Depend on it then I guess, if it's being used
> > in preinst actions. The thing is that Depends only after postinst ordering,
> > not unpack ordering.
> 
> Well it's not the preinst script, but the prerm script. The problem is
> unpacking libexpat1 before libc6 breaks libexpat1 and not usable
> anymore.

prerm is the very first script being called (see §6.6) and usually it is
the script of the version installed (only in error cases the script from
the version being upgraded to will be tried as detailed in the dpkg
messages) so I would argue that the dependencies (maybe) satisfied are
the dependencies of the installed version, not the one being installed
(argueably the dependency set of v1 and v2 could conflict with each
other, so if dependencies of v2 would be satisfied that means v1 script
would be bound to explode). But thats perhaps just the fear talking as
going with dependencies of v2 would probably result in a lot of hard
coding problems for apt & dpkg (and other low package managers).

In any case, the unpack of these packages is in the same dpkg call, so
if dpkg would have wanted it could have reordered them & apt has no idea
about maintainerscript in general, so I would say this isn't an apt bug.

(Althrough, if we decide on v2, I guess apt needs to change anyhow as
that same call thing might be just dumb luck in this case. Not even sure
if v1 is in any way "guaranteed" to be perfectly honest…)

Can't stop the feeling that we had issues with python begin called from
prerm before and the general advice was: "don't – stick to essential".


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Aurelien Jarno]

On 2018-01-18 20:38, Julian Andres Klode wrote:
> On Thu, Jan 18, 2018 at 06:41:52PM +0100, Aurelien Jarno wrote:
> > control: reassign -1 apt,dpkg
> > control: affects -1 libc6
> > control: affects -1 libexpat1
> > 
> > On 2018-01-18 15:53, Andreas Beckmann wrote:
> > > Package: libc6
> > > Version: 2.26-2
> > > Severity: serious
> > > User: debian...@lists.debian.org
> > > Usertags: piuparts
> > > 
> > > Hi,
> > > 
> > > during a test with piuparts I noticed your package fails to upgrade from
> > > 'stretch'.
> > > It installed fine in 'stretch', then the upgrade to 'buster' fails.
> > > 
> > > >From the attached log (scroll to the bottom...):
> > > 
> > > [...]
> > >   Preparing to unpack .../libexpat1-dev_2.2.5-3_i386.deb ...
> > >   Unpacking libexpat1-dev:i386 (2.2.5-3) over (2.2.0-2+deb9u1) ...
> > >   Preparing to unpack .../libexpat1_2.2.5-3_i386.deb ...
> > >   Unpacking libexpat1:i386 (2.2.5-3) over (2.2.0-2+deb9u1) ...
> > 
> > $ apt-cache show libexpat1
> > Package: libexpat1
> > Source: expat
> > Version: 2.2.5-3
> > Installed-Size: 429
> > Maintainer: Laszlo Boszormenyi (GCS) 
> > Architecture: i386
> > Depends: libc6 (>= 2.25)
> > 
> > So libexpat1 correctly depends on libc6 (>= 2.25), which is not
> > even unpacked at that point.
> > 
> > > [...]
> > >   Preparing to unpack .../3-libglib2.0-dev_2.54.3-1_i386.deb ...
> > >   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' 
> > > not found (required by /lib/i386-linux-gnu/libexpat.so.1)
> > >   dpkg: warning: subprocess old pre-removal script returned error exit 
> > > status 1
> > >   dpkg: trying script from the new package instead ...
> > >   dpkg: error processing archive 
> > > /tmp/apt-dpkg-install-wfemKS/3-libglib2.0-dev_2.54.3-1_i386.deb 
> > > (--unpack):
> > >there is no script in the new version of the package - giving up
> > >   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' 
> > > not found (required by /lib/i386-linux-gnu/libexpat.so.1)
> > 
> > This failure is normal given libexpat1 requires the new libc which has
> > not been unpacked yet.
> 
> Yeah, well, it needs to Pre-Depend on it then I guess, if it's being used
> in preinst actions. The thing is that Depends only after postinst ordering,
> not unpack ordering.

Well it's not the preinst script, but the prerm script. The problem is
unpacking libexpat1 before libc6 breaks libexpat1 and not usable
anymore.

From what I understand from the debian-policy, a prerm script might
consider that all the dependencies have been at least unpacked when
called:

| "The package whose prerm is being called will be at least
| “Half-Installed”. All package dependencies will at least be
| “Half-Installed” and will have previously been configured and not
| removed. If there was no error, all dependencies will at least be
| “Unpacked”, but these actions may be called in various error
| states where dependencies are only “Half-Installed” due to a
| partial upgrade.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Julian Andres Klode]

On Thu, Jan 18, 2018 at 08:38:02PM +0100, Julian Andres Klode wrote:
> On Thu, Jan 18, 2018 at 06:41:52PM +0100, Aurelien Jarno wrote:
> > control: reassign -1 apt,dpkg
> > control: affects -1 libc6
> > control: affects -1 libexpat1
> > 
> > On 2018-01-18 15:53, Andreas Beckmann wrote:
> > > Package: libc6
> > > Version: 2.26-2
> > > Severity: serious
> > > User: debian...@lists.debian.org
> > > Usertags: piuparts
> > > 
> > > Hi,
> > > 
> > > during a test with piuparts I noticed your package fails to upgrade from
> > > 'stretch'.
> > > It installed fine in 'stretch', then the upgrade to 'buster' fails.
> > > 
> > > >From the attached log (scroll to the bottom...):
> > > 
> > > [...]
> > >   Preparing to unpack .../libexpat1-dev_2.2.5-3_i386.deb ...
> > >   Unpacking libexpat1-dev:i386 (2.2.5-3) over (2.2.0-2+deb9u1) ...
> > >   Preparing to unpack .../libexpat1_2.2.5-3_i386.deb ...
> > >   Unpacking libexpat1:i386 (2.2.5-3) over (2.2.0-2+deb9u1) ...
> > 
> > $ apt-cache show libexpat1
> > Package: libexpat1
> > Source: expat
> > Version: 2.2.5-3
> > Installed-Size: 429
> > Maintainer: Laszlo Boszormenyi (GCS) 
> > Architecture: i386
> > Depends: libc6 (>= 2.25)
> > 
> > So libexpat1 correctly depends on libc6 (>= 2.25), which is not
> > even unpacked at that point.
> > 
> > > [...]
> > >   Preparing to unpack .../3-libglib2.0-dev_2.54.3-1_i386.deb ...
> > >   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' 
> > > not found (required by /lib/i386-linux-gnu/libexpat.so.1)
> > >   dpkg: warning: subprocess old pre-removal script returned error exit 
> > > status 1
> > >   dpkg: trying script from the new package instead ...
> > >   dpkg: error processing archive 
> > > /tmp/apt-dpkg-install-wfemKS/3-libglib2.0-dev_2.54.3-1_i386.deb 
> > > (--unpack):
> > >there is no script in the new version of the package - giving up
> > >   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' 
> > > not found (required by /lib/i386-linux-gnu/libexpat.so.1)
> > 
> > This failure is normal given libexpat1 requires the new libc which has
> > not been unpacked yet.
> 
> Yeah, well, it needs to Pre-Depend on it then I guess, if it's being used
> in preinst actions. The thing is that Depends only after postinst ordering,
> not unpack ordering.
> 

To be more precise: I guess libglib2.0-dev needs to predepend on python3 or on
libexpat1.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Julian Andres Klode]

On Thu, Jan 18, 2018 at 06:41:52PM +0100, Aurelien Jarno wrote:
> control: reassign -1 apt,dpkg
> control: affects -1 libc6
> control: affects -1 libexpat1
> 
> On 2018-01-18 15:53, Andreas Beckmann wrote:
> > Package: libc6
> > Version: 2.26-2
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> > 
> > Hi,
> > 
> > during a test with piuparts I noticed your package fails to upgrade from
> > 'stretch'.
> > It installed fine in 'stretch', then the upgrade to 'buster' fails.
> > 
> > >From the attached log (scroll to the bottom...):
> > 
> > [...]
> >   Preparing to unpack .../libexpat1-dev_2.2.5-3_i386.deb ...
> >   Unpacking libexpat1-dev:i386 (2.2.5-3) over (2.2.0-2+deb9u1) ...
> >   Preparing to unpack .../libexpat1_2.2.5-3_i386.deb ...
> >   Unpacking libexpat1:i386 (2.2.5-3) over (2.2.0-2+deb9u1) ...
> 
> $ apt-cache show libexpat1
> Package: libexpat1
> Source: expat
> Version: 2.2.5-3
> Installed-Size: 429
> Maintainer: Laszlo Boszormenyi (GCS) 
> Architecture: i386
> Depends: libc6 (>= 2.25)
> 
> So libexpat1 correctly depends on libc6 (>= 2.25), which is not
> even unpacked at that point.
> 
> > [...]
> >   Preparing to unpack .../3-libglib2.0-dev_2.54.3-1_i386.deb ...
> >   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' not 
> > found (required by /lib/i386-linux-gnu/libexpat.so.1)
> >   dpkg: warning: subprocess old pre-removal script returned error exit 
> > status 1
> >   dpkg: trying script from the new package instead ...
> >   dpkg: error processing archive 
> > /tmp/apt-dpkg-install-wfemKS/3-libglib2.0-dev_2.54.3-1_i386.deb (--unpack):
> >there is no script in the new version of the package - giving up
> >   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' not 
> > found (required by /lib/i386-linux-gnu/libexpat.so.1)
> 
> This failure is normal given libexpat1 requires the new libc which has
> not been unpacked yet.

Yeah, well, it needs to Pre-Depend on it then I guess, if it's being used
in preinst actions. The thing is that Depends only after postinst ordering,
not unpack ordering.

> 
> >   dpkg: error while cleaning up:
> >subprocess installed post-installation script returned error exit status 
> > 1
> > [...]
> >   Preparing to unpack .../9-libc6_2.26-2_i386.deb ...
> >   Unpacking libc6:i386 (2.26-2) over (2.24-11+deb9u1) ...
> >   Errors were encountered while processing:
> >/tmp/apt-dpkg-install-wfemKS/3-libglib2.0-dev_2.54.3-1_i386.deb
> 
> And libc6 2.26-2 is only unpacked afterwards.

does not matter.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Processed: Re: Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 apt,dpkg
Bug #887629 [libc6] libc6: bad upgrade path: libexpat1 unpacked and python3 
called before libc6 unpacked
Bug reassigned from package 'libc6' to 'apt,dpkg'.
No longer marked as found in versions glibc/2.26-2.
Ignoring request to alter fixed versions of bug #887629 to the same values 
previously set
> affects -1 libc6
Bug #887629 [apt,dpkg] libc6: bad upgrade path: libexpat1 unpacked and python3 
called before libc6 unpacked
Added indication that 887629 affects libc6
> affects -1 libexpat1
Bug #887629 [apt,dpkg] libc6: bad upgrade path: libexpat1 unpacked and python3 
called before libc6 unpacked
Added indication that 887629 affects libexpat1

-- 
887629: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887629
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked

[Aurelien Jarno]

control: reassign -1 apt,dpkg
control: affects -1 libc6
control: affects -1 libexpat1

On 2018-01-18 15:53, Andreas Beckmann wrote:
> Package: libc6
> Version: 2.26-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'stretch'.
> It installed fine in 'stretch', then the upgrade to 'buster' fails.
> 
> >From the attached log (scroll to the bottom...):
> 
> [...]
>   Preparing to unpack .../libexpat1-dev_2.2.5-3_i386.deb ...
>   Unpacking libexpat1-dev:i386 (2.2.5-3) over (2.2.0-2+deb9u1) ...
>   Preparing to unpack .../libexpat1_2.2.5-3_i386.deb ...
>   Unpacking libexpat1:i386 (2.2.5-3) over (2.2.0-2+deb9u1) ...

$ apt-cache show libexpat1
Package: libexpat1
Source: expat
Version: 2.2.5-3
Installed-Size: 429
Maintainer: Laszlo Boszormenyi (GCS) 
Architecture: i386
Depends: libc6 (>= 2.25)

So libexpat1 correctly depends on libc6 (>= 2.25), which is not
even unpacked at that point.

> [...]
>   Preparing to unpack .../3-libglib2.0-dev_2.54.3-1_i386.deb ...
>   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' not 
> found (required by /lib/i386-linux-gnu/libexpat.so.1)
>   dpkg: warning: subprocess old pre-removal script returned error exit status 
> 1
>   dpkg: trying script from the new package instead ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-wfemKS/3-libglib2.0-dev_2.54.3-1_i386.deb (--unpack):
>there is no script in the new version of the package - giving up
>   /usr/bin/python3: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.25' not 
> found (required by /lib/i386-linux-gnu/libexpat.so.1)

This failure is normal given libexpat1 requires the new libc which has
not been unpacked yet.

>   dpkg: error while cleaning up:
>subprocess installed post-installation script returned error exit status 1
> [...]
>   Preparing to unpack .../9-libc6_2.26-2_i386.deb ...
>   Unpacking libc6:i386 (2.26-2) over (2.24-11+deb9u1) ...
>   Errors were encountered while processing:
>/tmp/apt-dpkg-install-wfemKS/3-libglib2.0-dev_2.54.3-1_i386.deb

And libc6 2.26-2 is only unpacked afterwards.

> This was a test in an i386 chroot with --install-recommends enabled,
> the package tested was multimedia-devel.
> Note that this runs with apt from stretch since this is an upgrade test ...
> 
> Something (I don't know what) probably needs to get stricter dependencies.

I disagree. The dependencies of libexpat1 are correct, libexpat1 needs a
new libc6 and correctly depends on it. Therefore it's not a bug of libc6
nor libexpat1. It looks to me like a bug in apt or dpkg. I am therefore
reassigning the bug to these packages, so the maintainers can have a
look at the issue.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net