diff options
Diffstat (limited to 'README.MultiArch')
| -rw-r--r-- | README.MultiArch | 63 |
1 files changed, 0 insertions, 63 deletions
diff --git a/README.MultiArch b/README.MultiArch deleted file mode 100644 index 588419b8d..000000000 --- a/README.MultiArch +++ /dev/null @@ -1,63 +0,0 @@ -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]. - -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 -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. - - -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 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. - -[0] https://wiki.ubuntu.com/MultiarchSpec |