Goswin von Brederlow wrote: > Harald Dunkel <harald.dunkel@t-online.de> writes: > >> >>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. > > > And that is what the c102 / c2 is about. :) > I know, but as written before, IMHO the abi version number should not be encoded in the package name. Usually you just get a new abi, but no new functionality, so why introduce a new name? Just to work around the limitations of dpkg? It is my suggestion to extend dpkg instead. Some packages don't follow this naming convention, anyway (e.g. libglu1-xorg, libstdc++-4.0, others?). > Say every package provides libfoobar-c++abi2 that would mean you would > double the depends of every c++ package. Vou need versioned depends on > libs and provides can't be versioned. So you need to depend on both > the lib and the abi. Doesn't appending c2 sound better? > No. Of course it is more difficult for dpkg to verify both package dependencies and package attributes. But there are some differences between the package dependency list and the package attributes: The attributes must match exactly, and there is no recursion. It is still a string compare, as with the package name. > >>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. > > > The break you get anyway. If the library provides a different c++ abi > dpkg must not allow it to be used for your old package, no matter how > you implement this. > If the abi version gets a package attribute, then chances are high that I just have to rebuild my package to support a new abi. If the abi version gets encoded in the package name, then everybody with a C++ package has to - introduce a renamed package for the new abi - change the dependencies of his package to catch the other new package names - build the new package - make the old package obsolete sometimes Seems to be a lot of effort for something that should be hidden deep inside. > Hey, lets hope this is the last C++ transition ever. At least until > g++ 4.1 :) > What will happen if the abi changes just for one platform, lets say for the Arm cpu? Does everybody have to rename his packages again? Regards Harri
Attachment:
signature.asc
Description: OpenPGP digital signature