]> git.saurik.com Git - apt.git/blame_incremental - README.MultiArch
merged from David
[apt.git] / README.MultiArch
... / ...
CommitLineData
1Before we start with this topic: Note that MultiArch is not yet ready for
2prime time and/or for the casual user. The implementation is so far widely
3untested and only useful for developers of packagemanagment tools which
4use APT and his friends and maintainers of (upcoming) MultiArch packages.
5This README is especially NOT written for the casual user and is NOT a
6usage guide - you have been warned. It is assumed that the reader has
7at least a bit of knowledge about APT internals, dependency relations
8and the MultiArch spec [0].
9
10Note also that the toolchain isn't ready yet, e.g. while you can simulate
11the installation of MultiArch packages they will more sooner than later
12cause enormous problems if really installed as dpkg can't handle MultiArch
13yet (no, --force-{overwrite,architecture} aren't good options here).
14Other parts of the big picture are missing and/or untested too.
15You have been warned!
16
17
18The implementation is focused on NOT breaking existing singleArch-only
19applications and/or systems as this is the current status-quo for all
20systems. Also, many systems don't need (or can't make use of) MultiArch,
21so APT will proceed in thinking SingleArch as long as it is not explicitly
22told to handle MultiArch:
23To activate MultiArch handling you need to specify architectures you
24want to be considered by APT with the config list APT::Architectures
25(Insert architectures in order of preference).
26APT will download Packages files for all these architectures in the
27update step. Exception: In the sourcelist is the optionfield used:
28deb [ arch=amd64,i386 ] http://example.org/ experimental main
29(This optionfield is a NOP in previous apt versions)
30
31Internally in APT a package is represented as a PkgIterator -
32before MultiArch this PkgIterator was architecture unaware,
33only VerIterators include the architecture they came from.
34This is/was a big problem as all versions in a package are
35considered for dependency resolution, so pinning will not work in all cases.
36
37The problem is solved by a conceptional change:
38A PkgIterator is now architecture aware, so the packages
39of foobar for amd64 and for i386 are now for apt internal totally
40different packages. That is a good thing for e.g. pinning, but
41sometimes you need the information that such packages are belonging together:
42All these foobar packages therefore form a Group accessible with GrpIterators.
43Note that the GrpIterator has the same name as all the packages in this group,
44so e.g. apt-cache pkgnames iterates over GrpIterator to get the package names:
45This is compatible to SingleArch as a Group consists only of a single package
46and also to MultiArch as a Group consists of possible many packages which
47all have the same name and are therefore out of interest for pkgnames.
48
49
50Given all these internal changes it is quite interesting that the actual
51implementation of MultiArch is trivial: Some implicit dependencies and a few
52more provides are all changes needed to get it working. Especially noteworthy
53is that it wasn't needed to change the resolver in any way and other parts only
54need to be told about using GrpIterator instead of PkgIterator, so chances are
55good that libapt-applications will proceed to work without or at least only
56require minor changes, but your mileage may vary…
57
58
59Known Issues and/or noteworthy stuff:
60* The implementation is mostly untested, so it is very likely that APT will
61 eat your kids if you aren't as lucky as the author of these patches.
62
63[0] https://wiki.ubuntu.com/MultiarchSpec