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

Re: multiarch status update

"Olaf van der Spek" <olafvdspek@gmail.com> writes:

> On 5/10/06, Matt Taggart and others <taggart@debian.org> wrote:
>> For a couple years now a few of us have been talking about an idea called
>> "multiarch". This is a way to seamlessly allow support for multiple different
>> binary targets on the same system, for example running both i386-linux-gnu and
>> amd64-linux-gnu binaries on the same system (many other working combinations
>> exist as well). I have created a new page in the wiki to track info and status
> Does it also allow completely arbitrary combinations to be installed?

There are 3 cases that concern multiarch:

1) no Multiarch line (all old packages)

Only one architecture of this package can be installed and any depends
on this package must match the ABI. This keeps all existing debs
working as they work now. It is the only save assumption.

2) Multiarch: no

This package does not need to have multiple architectures installed
(and nearly always can't). That means any depends on it do not involve
the ABI. No library is in this package and any architecture will
fullfill the depends for any other.

Basicaly this means this is a binary package with only a command line
interface that is architecture independent.

3) Multiarch: yes

This package can have multiple architectures installed and any
depending package must have the matching ABI installed for it.

Any library package has to set this if they want to support
multiarch. All the essential, required and base libraries need to
support this as a minimum. X, gnome and kde almost certainly need this
too for the users benefit. More obscure libs can probably get away
with sticking to option 1.

>> * allow for seamless large ABI transitions
>> * allow users to smoothly migrate from one arch to another
>> * do things like "partial architectures" so that we can add weird
>>  processor variants without needing to add an entire new port to the
>>  pool/mirrors
>> * better assimilate the *BSD kernels and userspaces
>> * better support non-monopoly archs, since they may be able to run bits
>>  for other archs
>> * maybe even to do stuff like use non-native archs (with support for
>>  other binary targets) to build native bits (m68k emulator on
>>  superfast amd64?).
>> * other cool stuff
> Does it also allow multiple versions of the same package to be
> installed at the same time?
> For example, multiple minor versions or multiple major versions?

Only if they also differ in the architecture/abi.

This won't remove the need to rename libfoo1 to libfoo2 on ABI


Reply to: