[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dependency problems with Xorg

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

> 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



Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: