* apt-inst/deb/debfile.h:

[apt.git] / README.MultiArch

diff --git a/README.MultiArch b/README.MultiArch
index 92491631e7c7e0235a38a6e23eb047ae9c3bc1b6..588419b8dd84b35f3e78a430bce94dad334b17dc 100644 (file)
--- a/README.MultiArch
+++ b/README.MultiArch
@@ -7,6 +7,13 @@ usage guide - you have been warned. It is assumed that the reader has
 at least a bit of knowledge about APT internals, dependency relations
 and the MultiArch spec [0].
 
 at least a bit of knowledge about APT internals, dependency relations
 and the MultiArch spec [0].
 

+Note also that the toolchain isn't ready yet, e.g. while you can simulate
+the installation of MultiArch packages they will more sooner than later
+cause enormous problems if really installed as dpkg can't handle MultiArch
+yet (no, --force-{overwrite,architecture} aren't good options here).
+Other parts of the big picture are missing and/or untested too.
+You have been warned!
+

 
 The implementation is focused on NOT breaking existing singleArch-only
 applications and/or systems as this is the current status-quo for all
 
 The implementation is focused on NOT breaking existing singleArch-only
 applications and/or systems as this is the current status-quo for all


@@ -40,67 +47,17 @@ and also to MultiArch as a Group consists of possible many packages which
 all have the same name and are therefore out of interest for pkgnames.
 
 
 all have the same name and are therefore out of interest for pkgnames.
 
 

-Caused by the paragraph "Dependencies involving Architecture: all packages"
-in the MultiArch spec we have a second major conceptional change
-which could even break existing applications, but we hope for the best…
-An Architecture: all package is internally split into pseudo packages
-for all MultiArch Architectures and additional a package with the
-architecture "all" with no dependencies which is a dependency of all
-these architecture depending packages. While the architecture depending
-packages are mainly used for dependency resolution (a package of arch A which
-depends on an arch all package assumes that the dependencies of this package
-are also from arch A. Packages also sometimes change from any to all or v.v.)
-the arch "all" package is used for scheduling download/installation of the
-underlying "real" package. Note that the architecture depending packages can
-be detected with Pseudo() while the "all" package reports exactly this arch
-as package architecture and as pseudo architecture of the versions of this pkg.
-Beware: All versions of a "real" architecture all package will be report "all"
-as their architecture if asked with Arch() regardless if they are the "all" or
-the architecture depending packages. If you want to know the architecture this
-pseudo package was created for call Arch(true). Also, while the spec say that
-arch:all packages are not allowed to have a MultiArch flag APT assigns a
-special value to them: MultiArch: all.
-
-
-As you might guess this arch:all handling has a few problems (but we think so
-far that the problems are minor compared to the problems we would have with
-other implementations.)
-APT doesn't know which pseudo packages of such an arch all package are
-"installed" (to satisfy dependencies), so APT will generate a Cache in which
-all these pseudo packages are installed (e.g. apt-cache policy will display
-them all as installed). Later in the DepCache step it will "remove"
-all pseudo packages whose dependencies are not satisfied.
-The expense is that if the package state is broken APT could come to the
-conclusion to "remove" too many pseudo packages, but in a stable environment
-APT should never end up in a broken system state…
-
-

 Given all these internal changes it is quite interesting that the actual
 implementation of MultiArch is trivial: Some implicit dependencies and a few
 more provides are all changes needed to get it working. Especially noteworthy
 is that it wasn't needed to change the resolver in any way and other parts only
 Given all these internal changes it is quite interesting that the actual
 implementation of MultiArch is trivial: Some implicit dependencies and a few
 more provides are all changes needed to get it working. Especially noteworthy
 is that it wasn't needed to change the resolver in any way and other parts only

-need to be told about ignoring pseudo packages or using GrpIterator instead of
-PkgIterator, so chances are good that libapt-applications will proceed to work
-without or at least only require minor changes, but your mileage may vary…
+need to be told about using GrpIterator instead of PkgIterator, so chances are
+good that libapt-applications will proceed to work without or at least only
+require minor changes, but your mileage may vary…

 
 
 Known Issues and/or noteworthy stuff:
 * The implementation is mostly untested, so it is very likely that APT will
   eat your kids if you aren't as lucky as the author of these patches.
 
 
 Known Issues and/or noteworthy stuff:
 * The implementation is mostly untested, so it is very likely that APT will
   eat your kids if you aren't as lucky as the author of these patches.

-* the (install)size of a pseudo package is always NULL - if you want to know
-  the (install)size you need to get the info from the arch "all" package.
-* It is maybe confusing, but the arch "all" package does have the same versions
-  and in general roughly the same information with one subtil difference:
-  It doesn't have any dependency, regardless of the type. The pseudo packages
-  depend on this package.
-* apt-cache policy foobar on installed architecture all package foobar will
-  report all architecture depending packages as installed. Displaying here the
-  correct information would require to build the complete DepCache…
-* [BUG] An installed package which changes the architecture from any to all
-  (and v.v.) shows up in the NEW packages section instead of UPGRADE.
-* [TODO] Investigate the DepCache pseudo-package killer heuristic:
-  e.g. add more safety guards…
-* [FIXME] a few corner cases/missing features marked as FIXME in the code
-

 
 [0] https://wiki.ubuntu.com/MultiarchSpec
 
 [0] https://wiki.ubuntu.com/MultiarchSpec