[Matthias Klose] > Details of the planned C++ ABI change can be found at > > http://lists.debian.org/debian-release/2005/04/msg00153.html
There I find this remark: Appended is an updated version, the most notable change is to drop the 'c102' suffix from packages, if it exists. This way, we get rid off the "ugly" extension, and we don't support direct upgrades from woody to etch anyway. How will this work for already installed non-debian binaries. I am talking about binaries installed a long time ago by the system administrator, using the C++ ABI in woody. If this third party package depends on libfoo (with old C++ ABI, before c102 was added), how do we avoid that the program break when the machine in question is upgraded from sarge to etch? To elaborate, I talk about a machine installed with woody, where someone built their own package with some binary using the woody C++ ABI, next, they upgrade to sarge and get libfooc102 in addition to the libfoo library they are using, and then when etch is released, they upgrade to etch, and libfoo from woody is replaced with libfoo from etch, with a completely different C++ ABI. Is this the way it will work? Do we want it? Notice that I am not talking about a direct upgrade from woody to etch. I'm talking about an upgrade woody->sarge->etch. (I suspect we could avoid it by making sure all libraries using the c102 prefix use the c2 prefix in etch.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]