MultiarchSpec

Revision 2 as of 2009-05-19 13:43:25

Clear message

Summary

This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples.

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.

Rationale

The current handling of 32-bit software on the amd64 architecture is unwieldly in the extreme. A handful of libraries are packaged as "biarch" packages, building -386 variants using gcc -m32; most do not, and as a result are only available if they're included in ia32-libs, a monstrous source package that has to be updated to be kept in sync with each change to one of the component libraries, and now contains so many libraries that its "source" package (consisting primarily of copies of the i386 binary packages) weighs in as a 550MB tarball. Furthermore, many of these libraries have to be patched to specially handle running in a 64-bit environment because they load various plugins from a system path that is already occupied by the 32-bit library, resulting in added complexity in the code due to special-casing.

In all cases, the libraries (and some executables) have to be repackaged as amd64 packages, because dpkg and apt do not support sensible handling of cross-installation of i386 packages. This consumes archive space and developer time on an ongoing basis.

User stories

  • Phil wants to run VMware server on his 64-bit Ubuntu install, but it is only available as a 32-bit package. He enables use of the 32-bit repositories on his system in the Software Sources configuration, then selects the vmware i386 package from the Add/Remove menu. The dependencies on the i386 library packages are automatically resolved, including libpam-modules, and the packages are installed for him.

Assumptions

  • The multiarch directory scheme required in order to make library packages co-installable will be a target for FHS/LSB standardization in the future; but even if it does not become a standard, multiarch is preferable to the status quo, which also uses non-standard library directories for amd64 and is much more complex at the packaging level.
  • Since Debian Policy prohibits declaring shared libraries as Essential: yes, it is assumed that any undeclared dependencies on Essential}} packages on the part of multiarch packages is satisfied by the binaries from the native architecture, and there is no need to multi-arch-ify any of the {{{Essential packages.

Design

Filesystem layout

In order to seamlessly accomodate more than one ELF ABI on a system, the library for each (soname,ABI) tuple must have a unique path on the filesystem. The FHS attempts to address this for the amd64 case by requiring that /usr/lib be reserved for 32-bit libraries, with 64-bit libraries located in /usr/lib64. This design has a number of shortcomings:

  • This is not forwards-compatible with any future ABI changes, which would require further design work and further modification of packages to handle the addition of new paths. (Indeed, this is already a concern for the MIPS architecture, which has three distinct ABIs in use in parallel.)
  • The amd64 architecture must be special-cased in the library packaging, as the only architecture that uses /usr/lib64 instead of /usr/lib. (Two pre-existing 64-bit Linux ports, Alpha and IA-64, also used /usr/lib for their 64-bit libs.) This is unnecessary added complexity.
  • It does not address emulation use cases, such as qemu, which could integrate much better and more efficiently with the system if the packages for a qemu arch were co-installable.

The current design used by Debian and Ubuntu also fails on a key point where the FHS layout does not:

  • The path for x86 and x86-64 libraries varies depending on whether the system is natively 32-bit or 64-bit, so translating paths at install time is insufficient for the general case because some libraries need to embed plugin paths in the binaries themselves.

Multiarch seeks to address all of these issues, at the expense of a one-time transition, by migrating libraries to subdirectories that include the architecture triplet as part of the path:

   /lib/i386-linux-gnu
   /lib/x86_64-linux-gnu
   /usr/lib/i386-linux-gnu
   /usr/lib/x86_64-linux-gnu

More detailed rationale for this layout can be found in Tollef Fog Heen's original multiarch paper at <FIXME>.

Binary package control fields

Although a simple change to a configuration option (dpkg --force-architecture) is sufficient to permit installation of .debs built for another architecture, more information is needed if we want package managers to intelligently resolve the dependencies for these packages. Some dependencies on other packages, such as on ELF libraries, can only be satisfied by a package of the same architecture ("x->x dependency"); others, such as dependencies on an interpreter used by a maintainer script, can be satisfied by a package of any architecture as long as it's functional ("x->any dependency").

This spec introduces a new binary package field, to be set on any package that is intended to be co-installable with copies of itself from other architectures.

Multi-Arch: yes

Support for this field should be added to dpkg ASAP so that it will be propagated to the Packages files without the need for a time-consuming transition from XB-Multi-Arch to Multi-Arch. (Cf. the Vcs-* fields, for which there are still a number of packages declaring X-Vcs-* in the archive.)

If a package has this field set, the package manager must treat this package as not satisfying the dependency of any package of a different arch. If the field is not set, then the default behavior is that a package of any architecture may be used to satisfy the dependency. Preference should be given to a package for the native architecture if available; if it is not available, the package may automatically install any available package, regardless of architecture, or it may choose to make this an option controlled by user configuration.

Setting Multi-Arch: yes on a package which is Architecture: all is considered an error. dpkg-deb must refuse to generate a .deb with this combination of values. Behavior when trying to install such a package is undefined.

Because packages that are candidates for use of the Multi-Arch field are generally pre-existing libraries with long-lived SONAMEs, care must be taken to ensure that any Multi-Arch: yes package that depends on other libraries has strict versioned dependencies on the first versions of those other libraries that are guaranteed to set the Multi-Arch field; otherwise, the dependency may be incorrectly satisfied by an older version of the native library package. The most straightforward way to fulfill this requirement is for each library package to unconditionally bump its shlibs declaration when adding the Multi-Arch field.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

  • data migration, if any
  • redirects from old URLs to new ones, if any
  • how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.


CategorySpec