Re: An introduction to multiarch
Hi Goswin,
On Sat, Jul 25, 2009 at 11:57:12PM +0200, Goswin von Brederlow wrote:
> 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.
Thanks for this. I'm not sure we are at a point where having more people
helping is beneficial - I believe we already have enough people involved as
fit around the table at this stage - but having a user-oriented intro is
still useful in its own right.
> b) Add foreign-arch relationship / Multi-Arch: allowed
> Some packages can have both dependies that must match the ABI and
> dependies where the ABI is inconsequential. For example a library
> binding for perl (e.g. for gtk) contains binary data that must have
> the same ABI as the perl interpreter. On the other hand a binary
> package (not arch: all) may also contain architecture independent perl
> scripts. A perl interpreter from any architecture will run them just
> fine.
> For this the proposal adds "Multi-Arch: allowed" and "Depends:
> <package>:any" for this. The "Multi-Arch: allowed" is only there as a
> saftey precaution so packages don't wrongfully use "Depends:
> <package>:any".
> Unfortunately this needs changes in the archive software (DAK) and the
> package management. It will break compatibility with existing Debian
> installation so it needs to do be introduced with a release cycle
> between implementation and actual use.
I think it's worth noting that the only changes required on the archive
side, for the first iteration, are to do s/:same// over the package
relationships when interpreting them. Only when we start having packages
which are *only* installable by way of cross-arch dependencies do we need to
worry about the archive software actually understanding the extended depends
syntax.
They still have to wait a full release cycle before they can be used
since otherwise they're uninstallable with the old dpkg, and the first and
second iterations might very well fall within a single release cycle, so
we'll see what comes of that.
> 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:<architecture> has been discussed in the past, but has never been
part of this current spec, conflicting as it does with the requirement that
existing architectures in the archive keep their dependencies satisfiable
within a single architecture at this point.
> 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.
Sure the use cases for this syntax are straightforward, it just implies a
lot more work to support on the archive side and isn't critical to the core
of multiarch.
BTW, I think your example has a bug in it. Unless one of those
"wine-bin"s was meant to be another package, I think what we actually want
is this:
Package: wine
Version: 1.0.1-2
Depends: wine-bin (= 1.0.1-2)
Suggests: wine-bin:i386
Recommends: wine-bin:amd64
Package: wine-bin
Version: 1.0.1-2
Multi-Arch: foreign
This avoids the need for versioned conflicts. It also makes explicit that
wine-bin is Multi-Arch: foreign, since without that wine would need Depends:
wine-bin:any (or the Recommends: would be redundant).
> 3) apt sources extension
> Here I have to disagree with the proposal and I hope the proposal will
> be adjusted. So here is my counter proposal to this:
> The default architectures for a system will be configured via
> Apt::Architectures in /etc/apt/apt.conf. But sometimes an entry should
> not use the default. The existing Apt already supports the following
> syntax:
> deb [whatever you like] url suite component ...
> I propose to use this instead of appending the architectures at the
> end of the line. Also it should be possible to put other things in
> there. So I propose to use
> deb [key1=val1,val2,val3;key2=val4,val5;...] url suite component ...
> Or as specific example:
> deb [arch=i386] http://download.skype.com/linux/repos/debian/ stable non-free
> This keeps the soruces.list syntax compatible with existing apt and
> reuses the already existing parser code. A patch for this is already
> in the BTS as it can be added imediatly and would be usefull for
> ia32-apt-get.
> Steve please consider adapting this syntax and update the wiki.
This will need to be discussed with Michael Vogt as the lead apt maintainer;
I'll take this to him for consideration (it was still on my list to do so).
However, I don't see any reason users should need to enable multiarch prior
to dist-upgrading to squeeze, so the impact of having a syntax that's not
backwards-compatible should be minimal.
> 4) Implementation (migration)
> For most users activating multiarch would be a simple matter of
> putting
> Apt::Architectures {"amd64"; "i386";};
> in /etc/apt/apt.conf.d/multiarch (or any other apt conffile). This
> could also be done with a "multiarch" package that could auto detect
> possible architectures or ask with debconf.
I don't think this configuration belongs to apt, I think it belongs to dpkg.
Also, there will probably need to be a way to merge architecture
declarations from multiple files, to allow individual packages to ship
conffiles enabling a corresponding arch.
> Migrating ia32-libs, ia32-libs-gtk and amd64-libs will be tricky if
> not impossible to automate. The release notes might have to say that
> the user has to replace all packages depending on them with the
> respective i386 or amd64 packages after enabling multiarch.
Yes; I don't expect/intend for this to be a blocker.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: