Re: Dependency problems with Xorg
Goswin von Brederlow wrote: Harald Dunkel [EMAIL PROTECTED] 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 signature.asc Description: OpenPGP digital signature
Re: Dependency problems with Xorg
Harald Dunkel [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: Harald Dunkel [EMAIL PROTECTED] 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. A dpkg extension is rather difficult to add and needs to be added to stable before it can be used in unstable at all. If you can realy think of something simpler than mangling the name add it now and etch+1 can use it at the earliest. Some packages don't follow this naming convention, anyway (e.g. libglu1-xorg, libstdc++-4.0, others?). libglu1 has a C abi while internaly it uses c++. It doesn't need a transition. It actualy did do a transition (in the Provides) but that will be reversed again. libstdc++ doesn't follow the simple 'add c2' rule as it changes it soversion at the same time: libstdc++-4, libstdc++-5, libstdc++-6. It also needs to be installed in parallel with prior versions for different g++ versions to work. So, since the library has a new name anyway there is no point in also adding c102 or c2 on top of that. It's all in the transition rules. 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 You have to change some ABI field somewhere and update the shlibs file to state the new ABI. That is basicaly the same work. - change the dependencies of his package to catch the other new package names Dependencies are done by shlibs. No change there. You do have to change the Build-Depends to the -dev packages though, increase the version to the first transitioned one. Unless you find some magic to make dpkg and sbuild check the ABI of the libs the -dev package is for you still have to change Build-Depends. And what ABI should it check for? What if I want to build for an older ABI for oldlibs? So would every source have to Build-Depend on the ABI it wants to build for? Changing that is as difficult as changing the package name and a lot less obvious. Note that the buildd system can Dep-Wait on the new name but wouldn't have a clue about the ABI field. Or would all the -dev packages Provide an ABI and conflict with all other ABIs? Then you have to adjust those for every package again. - build the new package Needs to be done anyway. - make the old package obsolete sometimes ??? The package becomes obsolete on it's own. Seems to be a lot of effort for something that should be hidden deep inside. Let's put it this way: Renaming is proven to work well and is simple. Anything else seems to need a lot of changes and extra thought to get implemented the first time. 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? Yes and no. Depends. E.g. parts of the C ABI have changed for m68k and hppa but the porters will have to deal with that transition on their own without a global renaming scheme. Regards Harri MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependency problems with Xorg
On Sun, Jul 17, 2005 at 04:28:56PM +0200, Harald Dunkel wrote: 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. Look, nice theory, but we're dealing with the realities of Debian today. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependency problems with Xorg
Goswin von Brederlow wrote: yes welcome to the c++ abi transition Maybe this has been suggested before, but... Probably more C++ abi changes will follow. To support a smooth migration I would like to suggest to create empty packages describing the C++ abis. A package maintainer could add the C++ abi package to the dependency list. When a new C++ abi gets introduced, and the first packages with a dependency to the new abi package appear, then these packages are automagically put on hold till all packages in the whole dependency chain have been migrated. Surely the package name or the version number are the wrong place to describe the C++ abi. Just an idea. Regards Harri signature.asc Description: OpenPGP digital signature
Re: Dependency problems with Xorg
Harald Dunkel [EMAIL PROTECTED] writes: Goswin von Brederlow wrote: yes welcome to the c++ abi transition Maybe this has been suggested before, but... Probably more C++ abi changes will follow. To support a smooth migration I would like to suggest to create empty packages describing the C++ abis. A package maintainer could add the C++ abi package to the dependency list. When a new C++ abi gets introduced, and the first packages with a dependency to the new abi package appear, then these packages are automagically put on hold till all packages in the whole dependency chain have been migrated. Surely the package name or the version number are the wrong place to describe the C++ abi. Just an idea. Regards Harri 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? 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. To be save as apt-get user just use dist-upgrade as that won't remove package and selectively use install package when you think something is finished with its transition. Aptitude should be intelligent enought not to remove non-automatic packages to upgrade automatic ones. But I'm not sure about that. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependency problems with Xorg
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 signature.asc Description: OpenPGP digital signature
Re: Dependency problems with Xorg
Harald Dunkel [EMAIL PROTECTED] writes: 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. Yes. But you can only have packages of the old ABI OR of the new ABI installed. With the current way you can have packages of both abis matched if their depends chains don't overlap. E.g. you can install a apt compiled with g++-4.0 without kicking out every other c++ lib. 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. And that is what the c102 / c2 is about. :) 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? 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. Hey, lets hope this is the last C++ transition ever. At least until g++ 4.1 :) Regards Harri MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
