Re: Dependency problems with Xorg
Harald Dunkel <email@example.com> 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
> 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 :)