On Wed, Apr 16, 2003 at 02:56:21PM +0200, Bj?rn Stenberg wrote: > Colin Watson wrote: > > No, that's not what shlibdeps do either. See: > > > > > > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps > > Lovely, so it's simply the other way around (as Adam Conrad said > already). Thanks. > > However, it still means packages get bogus dependencies that keep them > out of testing. Even if the package in question was already accepted > in stable.
The dependencies aren't bogus (apart from the occasional mistake in a library's shlibs files). The reason why a library's shlibs get changed is that binaries built against one version of the library can't be guaranteed to run correctly against older versions. Stable is irrelevant here, because the package built for stable was built against an older version of the library. Binary dependencies are not the same as source dependencies. > Let me be blunt and ask: Is this a "we don't care, go away" issue or > why is this so difficult to discuss? The only practical and correct way that I know of to improve the situation would be to figure out some way to calculate package dependencies from symbol versions in certain libraries. That's very difficult and would probably involve a lot more work on the part of the maintainers of those libraries even if it could be implemented, though. I think it is much more productive to try to get infrastructure packages into a good enough state that major upgrades can move into testing more quickly: that is, fix real bugs! Mailing package maintainers asking them to loosen their shared library dependencies is not useful and is sometimes actively counterproductive (I've seen maintainers messing around trying to upload packages built against testing, not realizing that the autobuilders all build against unstable so this won't do any good anyway, which increases the time their package has to wait over what would have happened if they'd just left well alone). Cheers, -- Colin Watson [EMAIL PROTECTED]