[apt.git] / README.MultiArch

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
Commit	Line	Data
9a230738 DK	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
f1a5db64 DK	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
9a230738 DK	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
9a230738 DK	50	Given all these internal changes it is quite interesting that the actual
	51	implementation of MultiArch is trivial: Some implicit dependencies and a few
	52	more provides are all changes needed to get it working. Especially noteworthy
	53	is that it wasn't needed to change the resolver in any way and other parts only
28166356 DK	54	need to be told about using GrpIterator instead of PkgIterator, so chances are
	55	good that libapt-applications will proceed to work without or at least only
	56	require minor changes, but your mileage may vary…
9a230738 DK	57
	58
	59	Known Issues and/or noteworthy stuff:
	60	* The implementation is mostly untested, so it is very likely that APT will
	61	eat your kids if you aren't as lucky as the author of these patches.
9a230738 DK	62
9a230738 DK	63	[0] https://wiki.ubuntu.com/MultiarchSpec