From 9a230738b2287dc5316f601ff0b4765eff9d898d Mon Sep 17 00:00:00 2001 From: David Kalnischkies Date: Sat, 13 Feb 2010 00:39:10 +0100 Subject: Add a more or less useful README file for everything related to MultiArch and install it in the apt-doc package. --- README.MultiArch | 106 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 README.MultiArch (limited to 'README.MultiArch') diff --git a/README.MultiArch b/README.MultiArch new file mode 100644 index 000000000..92491631e --- /dev/null +++ b/README.MultiArch @@ -0,0 +1,106 @@ +Before we start with this topic: Note that MultiArch is not yet ready for +prime time and/or for the casual user. The implementation is so far widely +untested and only useful for developers of packagemanagment tools which +use APT and his friends and maintainers of (upcoming) MultiArch packages. +This README is especially NOT written for the casual user and is NOT a +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]. + + +The implementation is focused on NOT breaking existing singleArch-only +applications and/or systems as this is the current status-quo for all +systems. Also, many systems don't need (or can't make use of) MultiArch, +so APT will proceed in thinking SingleArch as long as it is not explicitly +told to handle MultiArch: +To activate MultiArch handling you need to specify architectures you +want to be considered by APT with the config list APT::Architectures +(Insert architectures in order of preference). +APT will download Packages files for all these architectures in the +update step. Exception: In the sourcelist is the optionfield used: +deb [ arch=amd64,i386 ] http://example.org/ experimental main +(This optionfield is a NOP in previous apt versions) + +Internally in APT a package is represented as a PkgIterator - +before MultiArch this PkgIterator was architecture unaware, +only VerIterators include the architecture they came from. +This is/was a big problem as all versions in a package are +considered for dependency resolution, so pinning will not work in all cases. + +The problem is solved by a conceptional change: +A PkgIterator is now architecture aware, so the packages +of foobar for amd64 and for i386 are now for apt internal totally +different packages. That is a good thing for e.g. pinning, but +sometimes you need the information that such packages are belonging together: +All these foobar packages therefore form a Group accessible with GrpIterators. +Note that the GrpIterator has the same name as all the packages in this group, +so e.g. apt-cache pkgnames iterates over GrpIterator to get the package names: +This is compatible to SingleArch as a Group consists only of a single package +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. + + +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 +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… + + +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 -- cgit v1.2.3 From f1a5db64ad03910c2a401af8baa80fe2354beaa7 Mon Sep 17 00:00:00 2001 From: David Kalnischkies Date: Wed, 17 Feb 2010 22:05:15 +0100 Subject: add a note about the uncomplete toolchain to sound a bit more scary --- README.MultiArch | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'README.MultiArch') diff --git a/README.MultiArch b/README.MultiArch index 92491631e..b2964ac38 100644 --- 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]. +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 -- cgit v1.2.3