Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames

[Petter Reinholdtsen <pere@hungry.com>]

[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.)