tags 41907 + confirmed
stop
Hi,
I'm still experiencing this bug today, and I suppose most people
generating udebs are:
bee% for i in udeb 0; do dpkg-shlibdeps -O
debian/libpango1.0-$i/usr/lib/libpangoft2-1.0.so.0.1400.0; done
shlibs:Depends=libc6 (>= 2.3.6-6), libfontconfig1 (>= 2.3.0), libfreetype6 (>=
2.2), libglib2.0-0 (>= 2.12.0), libpango1.0-0 (>= 1.14.0), zlib1g (>= 1:1.2.1)
shlibs:Depends=libc6 (>= 2.3.6-6), libfontconfig1 (>= 2.3.0), libfreetype6 (>=
2.2), libglib2.0-0 (>= 2.12.0), zlib1g (>= 1:1.2.1)
(Note that there's an added libpango1.0-0 dependency in the udeb; would
I be calling dpkg-shlibdeps with the proper flags, this would cause a
self dependency in libpango1.0-udeb.)
I've investigated this a little further, and found the cause to be:
1) binaries in the package which depend on the shared lib
2) special exception to not add self-dependencies in some cases in
dpkg-shlibdeps:
return 1 if $fn eq "$curpackdir/DEBIAN/shlibs";
(around 365)
However, the above test is incorrect: it tests whether the shlibs where
the dependencies comes from is in the same package as the binary which
needs the dependency. Instead, it should test whether the shlibs would
cause a dependency on the same package where the binary is from.
I think that both the incorrect and the proposed fixed behaviors are
both too clever for dpkg-shlibdeps, and it should simply permit
filtering the generated deps instead. This could for example be used
by dh_shlibdeps to implement the old behavior and permit the maintainer
to extend the filtering such as in the case of udebs.
Bye,
--
Loïc Minier <[EMAIL PROTECTED]>
