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