On Sun, Jun 05, 2005 at 03:04:45PM +0200, Petter Reinholdtsen wrote: > [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? Since the C++ transition *to* c102 naming involved conflicting with the previous version of the library (since the package name changed but the soname -- and therefore the filename -- did not), such third-party binaries are already unusable in sarge unless the user did not install the c102 package. So, this is only a problem for users that didn't have anything on their system which depends on the sarge version of the library. > (I suspect we could avoid it by making sure all libraries using the > c102 prefix use the c2 prefix in etch.) True, to the extent that it applies. -- Steve Langasek postmodern programmer
signature.asc
Description: Digital signature
