Bug#687076: libapt-pkg4.12 has a too loose versioned dependency on zlib1g
reassign 687076 zlib 1:1.2.3.3.dfsg-12
retitle 687076 gzseek64 and gztell64 symbols create too loose
versioned dependency
thanks
On Sun, Sep 9, 2012 at 1:36 PM, Marco d'Itri <md@linux.it> wrote:
> While we generally do not support upgrades which skip a release, I think
> we can all agree that we should avoid to break apt on upgrades if there
> is a simple fix.
[…]
> root@picard:~# apt-get install dpkg
> apt-get: /usr/lib/libz.so.1: version `ZLIB_1.2.3.3' not found (required by /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12)
> [Exit 1]
>
> I fixed this by manually installing zlib1g_1.2.7.dfsg-13_i386.deb.
> The old version was 1:1.2.3.3.dfsg-12.
I can't reproduce this on amd64, but I can on i386.
On i386 we use the gzseek64 and gztell64 which are both
from ZLIB_1.2.3.3 and explicitly set in the symbols file to 1:1.2.3.3
while the global setting for this symbol version is 1:1.2.3.4.
And indeed, if I use 1:1.2.3.4.dfsg-1 everything is fine.
The changelog entry of that version indicates that 64 was remodeled
in that release, so I guess the symbols file is wrong in downgrading
the version for at least one of these two symbols.
I am therefore reassigning to zlib so they can have a look.
A quick grep over the packages in main with "zlib1g (>= 1:1.2.3.3)"
reveals 61 packages which are possibly effected.
If I remove the packages with the same dependency in amd64
I still get 23 packages in response.
grep -h -e '^Package:' -e '^Depends'
/var/lib/apt/lists/*_wheezy_main_binary-{i386,amd64}_Packages | grep
-B 1 'zlib1g (>= 1:1.2.3.3)' | grep '^Package:' | sort | uniq -u
(yeah, I know, that is probably replaceable with a funky sed/awk line,
but I am lazy and I like grep)
APT could possibly just depend unconditional on all archs on 1:1.2.3.4
to help dpkg-shlibdeps, but lets see what the zlib maintainer says first
as this doesn't fix other possibly effected packages …
Best regards
David Kalnischkies
Reply to: