Re: Dependency problems with Xorg
Harald Dunkel <harald.dunkel@t-online.de> writes:
> 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.
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
Reply to: