| | 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 | Caused by the paragraph "Dependencies involving Architecture: all packages" |
| | 51 | in the MultiArch spec we have a second major conceptional change |
| | 52 | which could even break existing applications, but we hope for the best… |
| | 53 | An Architecture: all package is internally split into pseudo packages |
| | 54 | for all MultiArch Architectures and additional a package with the |
| | 55 | architecture "all" with no dependencies which is a dependency of all |
| | 56 | these architecture depending packages. While the architecture depending |
| | 57 | packages are mainly used for dependency resolution (a package of arch A which |
| | 58 | depends on an arch all package assumes that the dependencies of this package |
| | 59 | are also from arch A. Packages also sometimes change from any to all or v.v.) |
| | 60 | the arch "all" package is used for scheduling download/installation of the |
| | 61 | underlying "real" package. Note that the architecture depending packages can |
| | 62 | be detected with Pseudo() while the "all" package reports exactly this arch |
| | 63 | as package architecture and as pseudo architecture of the versions of this pkg. |
| | 64 | Beware: All versions of a "real" architecture all package will be report "all" |
| | 65 | as their architecture if asked with Arch() regardless if they are the "all" or |
| | 66 | the architecture depending packages. If you want to know the architecture this |
| | 67 | pseudo package was created for call Arch(true). Also, while the spec say that |
| | 68 | arch:all packages are not allowed to have a MultiArch flag APT assigns a |
| | 69 | special value to them: MultiArch: all. |
| | 70 | |
| | 71 | |
| | 72 | As you might guess this arch:all handling has a few problems (but we think so |
| | 73 | far that the problems are minor compared to the problems we would have with |
| | 74 | other implementations.) |
| | 75 | APT doesn't know which pseudo packages of such an arch all package are |
| | 76 | "installed" (to satisfy dependencies), so APT will generate a Cache in which |
| | 77 | all these pseudo packages are installed (e.g. apt-cache policy will display |
| | 78 | them all as installed). Later in the DepCache step it will "remove" |
| | 79 | all pseudo packages whose dependencies are not satisfied. |
| | 80 | The expense is that if the package state is broken APT could come to the |
| | 81 | conclusion to "remove" too many pseudo packages, but in a stable environment |
| | 82 | APT should never end up in a broken system state… |
| | 83 | |
| | 84 | |
| | 85 | Given all these internal changes it is quite interesting that the actual |
| | 86 | implementation of MultiArch is trivial: Some implicit dependencies and a few |
| | 87 | more provides are all changes needed to get it working. Especially noteworthy |
| | 88 | is that it wasn't needed to change the resolver in any way and other parts only |
| | 89 | need to be told about ignoring pseudo packages or using GrpIterator instead of |
| | 90 | PkgIterator, so chances are good that libapt-applications will proceed to work |
| | 91 | without or at least only require minor changes, but your mileage may vary… |
| | 92 | |
| | 93 | |
| | 94 | Known Issues and/or noteworthy stuff: |
| | 95 | * The implementation is mostly untested, so it is very likely that APT will |
| | 96 | eat your kids if you aren't as lucky as the author of these patches. |
| | 97 | * the (install)size of a pseudo package is always NULL - if you want to know |
| | 98 | the (install)size you need to get the info from the arch "all" package. |
| | 99 | * It is maybe confusing, but the arch "all" package does have the same versions |
| | 100 | and in general roughly the same information with one subtil difference: |
| | 101 | It doesn't have any dependency, regardless of the type. The pseudo packages |
| | 102 | depend on this package. |
| | 103 | * apt-cache policy foobar on installed architecture all package foobar will |
| | 104 | report all architecture depending packages as installed. Displaying here the |
| | 105 | correct information would require to build the complete DepCache… |
| | 106 | * [BUG] An installed package which changes the architecture from any to all |
| | 107 | (and v.v.) shows up in the NEW packages section instead of UPGRADE. |
| | 108 | * [TODO] Investigate the DepCache pseudo-package killer heuristic: |
| | 109 | e.g. add more safety guards… |
| | 110 | * [FIXME] a few corner cases/missing features marked as FIXME in the code |
| | 111 | |
| | 112 | |
| | 113 | [0] https://wiki.ubuntu.com/MultiarchSpec |
projects / apt.git / blame_incremental