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

Re: An introduction to multiarch

"Joe Smith" <unknown_kev_cat@hotmail.com> writes:

> "Goswin von Brederlow" <goswin-v-b@web.de> wrote in message
> [🔎] 87y6qczarr.fsf@frosties.localdomain">news:[🔎] 87y6qczarr.fsf@frosties.localdomain...
>> Hi,
>> after listening to the "Multiarch round table" talk at Debconf I feel
>> that the talk was targeted at people already familiar with the subject
>> and jumped right in at full speed. Someone new to the idea was
>> probably lost in the first minute.
>> So I decided to write an introduction to the problem that focuses more
>> on the user side, why we want multiarch at all, what goals and
>> requirements are to be met and gives some pointers. I leave the
>> techincal details to the actual proposal. Hopefully that helps more
>> people to jump on the wagon and help. Note that this is to be taken
>> together with the proposal itself:
>>  https://wiki.ubuntu.com/MultiarchSpec
> Looking at that proposal I see the following.
> +----------------+--------------+---------------------------+
> |Multi-arch Field|Co-installable|satifies cross-arch depends|
> +================+==============+===========================+
> | Not Present    |      No      |             ???           |
> +----------------+--------------+---------------------------+
> | Same           |      Yes     |             No            |
> +----------------+--------------+---------------------------+
> | foreign        |      No      |             Yes           |
> +----------------+--------------+---------------------------+
> | allowed        |    ??????    |specified by depending pkg |
> +----------------+--------------+---------------------------+

> It is not clear to me what goes in the remaining boxes, based on the
> current proposal. I would guess that with no Multi-arch feild present,
> it does not satisfiy cross-arch depends, and that "Multi-arch:
> allowed" implies co-installability.

'Not Present' is what all existing packages have and they do not
satify cross-arch depends. That is the only answere that won't break
things (arch: all packages excepted, they are different).

As for allowed that won't work as co-installable. Take python as
example. Imagine having a 32bit python and gtk bindings and 64bit
python and qt bindings installed. Now what should happen when the user
starts a python script? If the script uses gtk it must use the 32bit
python. If the script uses qt it must use the 64bit python. That would
be a HUGE mess.

The only sane solution here is that binaries are not coinstallable and
only binaries can be "allowed".

>> a) Add Multi-Arch field (same/foreign)
>> The Multi-Arch field is introduced into the depended on package and
>> governs how depending packages behave. That means Debian packages need
>> to be changed and then existing 3rd party debs like google earth will
>> become installable. The 3rd party debs itself does not need to change
>> to benefit from Debian going multiarch.
>> This covers all cases of dependencies between binaries and
>> libraries. It does not cover scripting languages with binary
>> extensions (perl, python, ...) where some dependencies must match the
>> ABI and some don't.
>> In particular all bi-/tri-arch cases currently supported are covered
>> by this.
> Based on this, I'm going to guess that this means that standard
> libraries will marked as "Multi-arch: Same". Is that right?

And potentially/eventually all others too. From my experience with
ia32-libs and ia32-apt-get there are <200 libraries people actualy
need in 32bit on amd64. Those are prime candidates to become
"Multi-arch: Same" first.

> I'm still not entirely clear on when "Multi-arch:foreign" would be
> used. Would it be for binaries packages that do not support
> co-installibility, but whose functionality does not differ between
> architectures, so any installed version would work? Utilities like
> wget come to mind.

No binary package will support co-installability. That is outside the
scope of the proposal and raises to many problems with existing
systems. A /usr/bin/tripplet/foo won't work for #!/usr/bin/foo scripts
and so on.

On the other hand you need "Multi-arch:foreign" so foreign packages
depending on it become installable at all. So again all the standard
binary packages will need to add "Multi-arch:foreign" fairly quickly.

Which raises an interesting point concerning essential packages. Since
packages do not depend on them all essential packages bust be
"Multi-arch:foreign" or co-installed for all activated architectures.
I'm not sure anyone has gone through all the essential packages yet
checking if they can all be "Multi-arch:foreign". Without promising
anything I think that should be the case since libraries are never

>> Add-on:
>> The current implementation restricts the new dependency syntax to
>> "<package>:any". Earlier on there was also "<package>:<architecture>"
>> on the board but is now listed as unsuported by the
>> implementation. Hopefully this will come back. A use case for this
>> will be wine. It could look something like this:
>> Package: wine
>> Version: 1.0.1-2
>> Depends: wine-bin
>> Suggests: wine-bin:i386
>> Recommends: wine-bin:amd64
>> Conflicts: wine-bin (<< 1.0.1-2), wine-bin (>> 1.0.1-2)
>> The reason for this is that future wine will support both the win32
>> ABI and win64 ABI allowing executing 32bit and 64bit windows
>> applications. Wine is usefull with either 32bit or 64bit support (so
>> it depends on wine-bin for any architecture) but nearly all users want
>> the 32bit wine.
> If nearly all users want the 32bit wine, should it not be
> "Recommends: wine-bin:i386"? (In that case the suggests should also be
> swapped. Further, I presume said suggest line would only appear on
> AMD64 packages, since "wine-bin:amd64" would be useless on i386, right?

Yeah, I always get the two mixed.

> I am just a user, but of the suggested changes to the multi-arch
> proposal, all of them sound good. In particular, utilizing the
> undocumented vendor feild as an attribute feild sounds like a good
> idea, assuming it is not actually used anywhere (if it is used in the
> rpm port, or by some other user, it is a non-starter).

The apt source in Debian parses the [vendor] field and throws it
away. It is simply skipped during parsing, at least in Debian.

> Also for the record, the bug Goswin mentioned with the patch is bug
> 536029


Reply to: