Re: An introduction to multiarch
"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.
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?
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.
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?
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).
Also for the record, the bug Goswin mentioned with the patch is bug 536029
Reply to: