>a) libkpathsea: It has a new soname, and I have not checked at all > whether this causes problems in compiling other packages. This means libkpathsea3 will no longer be available in unstable, right?
I have attempted to check whether this could cause any trouble in transitions to testing (by linking transitions together). I checked whether there were any packages depending on libkpathsea which also depend on a C++ library which needs to transition and hasn't made it to "testing" yet. If so, you'd be in trouble, because such a package would tie the transitions together: the new version can't move until libkpathsea4 *and* the updated C++ library move, and neither library can move without breaking the old version, so they all have to go together. The only bad case I found was "evince". This one is trouble, since it's dependent on GNOME. It would cause a pretty nasty tangle. So you ought to wait to upload new teTeX until a C++-transitioned "evince" makes it to etch. Luckily evince has only one rdepends (gnome-desktop-environment). I think that's all that needs to be checked; recursive reverse depends shouldn't be a problem w.r.t. a soname change. If a package involved in another transition acquired a versioned dependency on the newest tetex, of course, it would have the same tying effect, but that doesn't seem likely. A similar problem would happen with X libraries, but only if the package depended on an X library which changed name or soname (or ABI), or had a new versioned dependency on a recent version of an X library, and I don't think there are any interesting cases there. So I think it's safe to upload after evince makes it to etch. However, one other point: why is libkpathsea-dev being replaced with libkpathsea4-dev? Did the API change? If so, changing the name is correct, but the transition will involve serious work on the part of the maintainers of every depending package and they should be warned. If not, changing the name is a bad idea and causes unnecessary trouble. -- This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]