Re: Bug#887629: libc6: bad upgrade path: libexpat1 unpacked and python3 called before libc6 unpacked
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 to: