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 | ??? |
No
> +----------------+--------------+---------------------------+
> | Same | Yes | No |
> +----------------+--------------+---------------------------+
> | foreign | No | Yes |
> +----------------+--------------+---------------------------+
> | allowed | ?????? |specified by depending pkg |
> +----------------+--------------+---------------------------+
No
> 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
essential.
>> 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
MfG
Goswin
Reply to: