Control: clone -1 -2 Control: reassign -1 pypy 7.3.3+dfsg-1 Control: retitle -1 pypy: ${shlibs:Depends} must move to Pre-Depends Control: affects -1 pypy-stem Control: reassign -2 pypy3 7.3.3+dfsg-3 Control: retitle -2 pypy3: ${shlibs:Depends} must move to Pre-Depends
On Fri, Apr 30, 2021 at 01:48:34PM +0300, Adrian Bunk wrote: > On Mon, Apr 19, 2021 at 08:41:14PM +0200, Andreas Beckmann wrote: > >... > > Preparing to unpack .../pypy-stem_1.8.0-3_all.deb ... > > /usr/bin/pypy: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not > > found (required by /usr/lib/pypy/bin/libpypy-c.so) > > dpkg: warning: old pypy-stem package pre-removal script subprocess > > returned error exit status 1 > > dpkg: trying script from the new package instead ... > > /usr/bin/pypy: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not > > found (required by /usr/lib/pypy/bin/libpypy-c.so) > > dpkg: error processing archive > > /var/cache/apt/archives/pypy-stem_1.8.0-3_all.deb (--unpack): > > new pypy-stem package pre-removal script subprocess returned error exit > > status 1 > > /usr/bin/pypy: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not > > found (required by /usr/lib/pypy/bin/libpypy-c.so) > > dpkg: error while cleaning up: > > installed pypy-stem package post-installation script subprocess returned > > error exit status 1 > > Errors were encountered while processing: > > /var/cache/apt/archives/pypy-stem_1.8.0-3_all.deb > > > > The problem: at the point where pypy-stem gets unpacked (und thus > > 'prerm upgrade' is run), the new pypy has already been unpacked but > > the new libc6 is not yet unpacked. > > This should be solvable by adding Pre-depends: pypy to pypy-stem > > (to ensure pypy is in a usable state). > > But this looks more like a general problem that could happen in all > > pypy packages ... > > The solution to the general problem would be to turn the pypy and pypy3 > Depends into Pre-Depends? As discussed on IRC, I am cloning and reassigning. cu Adrian