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]>