| 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 |