README.MultiArch

   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
  11 The implementation is focused on NOT breaking existing singleArch-only
  12 applications and/or systems as this is the current status-quo for all
  13 systems. Also, many systems don't need (or can't make use of) MultiArch,
  14 so APT will proceed in thinking SingleArch as long as it is not explicitly
  15 told to handle MultiArch:
  16 To activate MultiArch handling you need to specify architectures you
  17 want to be considered by APT with the config list APT::Architectures
  18 (Insert architectures in order of preference).
  19 APT will download Packages files for all these architectures in the
  20 update step. Exception: In the sourcelist is the optionfield used:
  21 deb [ arch=amd64,i386 ] http://example.org/ experimental main
  22 (This optionfield is a NOP in previous apt versions)
  23
  24 Internally in APT a package is represented as a PkgIterator -
  25 before MultiArch this PkgIterator was architecture unaware,
  26 only VerIterators include the architecture they came from.
  27 This is/was a big problem as all versions in a package are
  28 considered for dependency resolution, so pinning will not work in all cases.
  29
  30 The problem is solved by a conceptional change:
  31 A PkgIterator is now architecture aware, so the packages
  32 of foobar for amd64 and for i386 are now for apt internal totally
  33 different packages. That is a good thing for e.g. pinning, but
  34 sometimes you need the information that such packages are belonging together:
  35 All these foobar packages therefore form a Group accessible with GrpIterators.
  36 Note that the GrpIterator has the same name as all the packages in this group,
  37 so e.g. apt-cache pkgnames iterates over GrpIterator to get the package names:
  38 This is compatible to SingleArch as a Group consists only of a single package
  39 and also to MultiArch as a Group consists of possible many packages which
  40 all have the same name and are therefore out of interest for pkgnames.
  41
  42
  43 Caused by the paragraph "Dependencies involving Architecture: all packages"
  44 in the MultiArch spec we have a second major conceptional change
  45 which could even break existing applications, but we hope for the best…
  46 An Architecture: all package is internally split into pseudo packages
  47 for all MultiArch Architectures and additional a package with the
  48 architecture "all" with no dependencies which is a dependency of all
  49 these architecture depending packages. While the architecture depending
  50 packages are mainly used for dependency resolution (a package of arch A which
  51 depends on an arch all package assumes that the dependencies of this package
  52 are also from arch A. Packages also sometimes change from any to all or v.v.)
  53 the arch "all" package is used for scheduling download/installation of the
  54 underlying "real" package. Note that the architecture depending packages can
  55 be detected with Pseudo() while the "all" package reports exactly this arch
  56 as package architecture and as pseudo architecture of the versions of this pkg.
  57 Beware: All versions of a "real" architecture all package will be report "all"
  58 as their architecture if asked with Arch() regardless if they are the "all" or
  59 the architecture depending packages. If you want to know the architecture this
  60 pseudo package was created for call Arch(true). Also, while the spec say that
  61 arch:all packages are not allowed to have a MultiArch flag APT assigns a
  62 special value to them: MultiArch: all.
  63
  64
  65 As you might guess this arch:all handling has a few problems (but we think so
  66 far that the problems are minor compared to the problems we would have with
  67 other implementations.)
  68 APT doesn't know which pseudo packages of such an arch all package are
  69 "installed" (to satisfy dependencies), so APT will generate a Cache in which
  70 all these pseudo packages are installed (e.g. apt-cache policy will display
  71 them all as installed). Later in the DepCache step it will "remove"
  72 all pseudo packages whose dependencies are not satisfied.
  73 The expense is that if the package state is broken APT could come to the
  74 conclusion to "remove" too many pseudo packages, but in a stable environment
  75 APT should never end up in a broken system state…
  76
  77
  78 Given all these internal changes it is quite interesting that the actual
  79 implementation of MultiArch is trivial: Some implicit dependencies and a few
  80 more provides are all changes needed to get it working. Especially noteworthy
  81 is that it wasn't needed to change the resolver in any way and other parts only
  82 need to be told about ignoring pseudo packages or using GrpIterator instead of
  83 PkgIterator, so chances are good that libapt-applications will proceed to work
  84 without or at least only require minor changes, but your mileage may vary…
  85
  86
  87 Known Issues and/or noteworthy stuff:
  88 * The implementation is mostly untested, so it is very likely that APT will
  89   eat your kids if you aren't as lucky as the author of these patches.
  90 * the (install)size of a pseudo package is always NULL - if you want to know
  91   the (install)size you need to get the info from the arch "all" package.
  92 * It is maybe confusing, but the arch "all" package does have the same versions
  93   and in general roughly the same information with one subtil difference:
  94   It doesn't have any dependency, regardless of the type. The pseudo packages
  95   depend on this package.
  96 * apt-cache policy foobar on installed architecture all package foobar will
  97   report all architecture depending packages as installed. Displaying here the
  98   correct information would require to build the complete DepCache…
  99 * [BUG] An installed package which changes the architecture from any to all
 100   (and v.v.) shows up in the NEW packages section instead of UPGRADE.
 101 * [TODO] Investigate the DepCache pseudo-package killer heuristic:
 102   e.g. add more safety guards…
 103 * [FIXME] a few corner cases/missing features marked as FIXME in the code
 104
 105
 106 [0] https://wiki.ubuntu.com/MultiarchSpec