Goswin von Brederlow wrote: > > A single C++-ABI package would just mean that all c++ packages are > kept back (or removed) from the very start of the c++ transition up to > the very end. There will be a lot of packages at the end of the > dependency chains that you don't have installed and that will take > long to fix. Do you realy want to wait for every last one to get > fixed? > The dependencies are verified just for the installed packages, plus the newly selected, minus the packages to be deinstalled, AFAIK. To avoid waiting I could remove packages sticking to the old abi. > Even worse you couldn't install g++-3.3 and g++-3.4/4.0 in parallel as > the libstdc++s would depend on conflicting C++-ABI packages. > But the ABIs conflict, anyway, regardless whether there is yet another package or not. A clean way to create packages for the new abi is to debootstrap a new chroot without references to the old abi, and use this environment for building and testing. But I can follow your argument. Dpkg should allow installing different C++ abis on the same machine. Only within each dependency chain the abi version number must be unique, so it should become some kind of package attribute. This would allow dpkg to verify the abi version. I just want to avoid that somebody else breaks the dependencies of my package by dropping the old name and introducing a new one for the same library, just because we changed a low level interface that usually should be transparent to everybody. Regards Harri
Attachment:
signature.asc
Description: OpenPGP digital signature