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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: 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: [hidden email]
> 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) <[hidden email]>
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
[hidden email]                 http://www.aurel32.net

Reply | Threaded
Open this post in threaded view
|

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

Julian Andres Klode-4
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: [hidden email]
> > 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) <[hidden email]>
> 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

Reply | Threaded
Open this post in threaded view
|

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

Julian Andres Klode-4
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: [hidden email]
> > > 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) <[hidden email]>
> > 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

Reply | Threaded
Open this post in threaded view
|

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

Aurelien Jarno
In reply to this post by Julian Andres Klode-4
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: [hidden email]
> > > 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) <[hidden email]>
> > 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
[hidden email]                 http://www.aurel32.net

Reply | Threaded
Open this post in threaded view
|

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

David Kalnischkies-4
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Andreas Beckmann-4
In reply to this post by Aurelien Jarno
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

Reply | Threaded
Open this post in threaded view
|

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

Andreas Beckmann-4
In reply to this post by David Kalnischkies-4
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

Reply | Threaded
Open this post in threaded view
|

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

Guillem Jover
In reply to this post by Aurelien Jarno
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