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
