Re: multiarch/bi-arch status (ETA) question
bob@proulx.com (Bob Proulx) writes:
> Thomas Steffen wrote:
>> The better way to do it is to have three (sub)packages: i386, x86_64
>> and shared. That is a bit like -common and -bin, but the packages
>> differ only in architecture, not in the name. Imho that is the way to
>> go.
>>
>> However, if you look closer, you find that both approaches impose the
>> same restrictions: all two or three (sub)packages have to be exactly
>> the same version, they have to match. So you can't upgrade one without
>> upgrading the other(s).
>
> That all depends on if the relationship is == or >=. It shouldn't if
> it is a >= dependency. But I am not sure that is practical for
> /usr/share files in general. But splitting that many packages would
> certainly increase the number of descrete packages hugely.
It also isn't a problem for debian. There are lots of packages that
are already interlocked with a 'foo (= 1.2-3)' depends and apt and
friends know how do deal with those without any problems. Every
library package is already interlocked with its -dev counterpart that
way.
>> I think this severely limits the ability to install third-party i386
>> software on a RedHat x86_64 system. As soon as the third-party
>> software requires a library upgrade, you get conflicts. (Now that
>> problem isn't new either, it is the reason behind DLL hell...)
Debian takes great care in changing SONAME and ABINAME whenever they
need changing. That means that things don't break when you have to
upgrade a library and different sonames of a library are usualy made
to coexist.
> But wait, most people who install RH systems don't actually ever
> upgrade. At the time they put the install cdrom in the box they
> install everything because they have been taught by experience that
> upgrades later don't work, better grab it now. So if they go to
> install something later it needs a newer library they consider that
> application completely unsupported on version X and think "I need to
> reinstall the system from scratch to get to version Y so that this
> application will run", no matter how trivial the requirement.
>
> Bob
MfG
Goswin
Reply to: