47
47
all have the same name and are therefore out of interest for pkgnames.
50
Caused by the paragraph "Dependencies involving Architecture: all packages"
51
in the MultiArch spec we have a second major conceptional change
52
which could even break existing applications, but we hope for the best…
53
An Architecture: all package is internally split into pseudo packages
54
for all MultiArch Architectures and additional a package with the
55
architecture "all" with no dependencies which is a dependency of all
56
these architecture depending packages. While the architecture depending
57
packages are mainly used for dependency resolution (a package of arch A which
58
depends on an arch all package assumes that the dependencies of this package
59
are also from arch A. Packages also sometimes change from any to all or v.v.)
60
the arch "all" package is used for scheduling download/installation of the
61
underlying "real" package. Note that the architecture depending packages can
62
be detected with Pseudo() while the "all" package reports exactly this arch
63
as package architecture and as pseudo architecture of the versions of this pkg.
64
Beware: All versions of a "real" architecture all package will be report "all"
65
as their architecture if asked with Arch() regardless if they are the "all" or
66
the architecture depending packages. If you want to know the architecture this
67
pseudo package was created for call Arch(true). Also, while the spec say that
68
arch:all packages are not allowed to have a MultiArch flag APT assigns a
69
special value to them: MultiArch: all.
72
As you might guess this arch:all handling has a few problems (but we think so
73
far that the problems are minor compared to the problems we would have with
74
other implementations.)
75
APT doesn't know which pseudo packages of such an arch all package are
76
"installed" (to satisfy dependencies), so APT will generate a Cache in which
77
all these pseudo packages are installed (e.g. apt-cache policy will display
78
them all as installed). Later in the DepCache step it will "remove"
79
all pseudo packages whose dependencies are not satisfied.
80
The expense is that if the package state is broken APT could come to the
81
conclusion to "remove" too many pseudo packages, but in a stable environment
82
APT should never end up in a broken system state…
85
50
Given all these internal changes it is quite interesting that the actual
86
51
implementation of MultiArch is trivial: Some implicit dependencies and a few
87
52
more provides are all changes needed to get it working. Especially noteworthy
88
53
is that it wasn't needed to change the resolver in any way and other parts only
89
need to be told about ignoring pseudo packages or using GrpIterator instead of
90
PkgIterator, so chances are good that libapt-applications will proceed to work
91
without or at least only require minor changes, but your mileage may vary…
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…
94
59
Known Issues and/or noteworthy stuff:
95
60
* The implementation is mostly untested, so it is very likely that APT will
96
61
eat your kids if you aren't as lucky as the author of these patches.
97
* the (install)size of a pseudo package is always NULL - if you want to know
98
the (install)size you need to get the info from the arch "all" package.
99
* It is maybe confusing, but the arch "all" package does have the same versions
100
and in general roughly the same information with one subtil difference:
101
It doesn't have any dependency, regardless of the type. The pseudo packages
102
depend on this package.
103
* apt-cache policy foobar on installed architecture all package foobar will
104
report all architecture depending packages as installed. Displaying here the
105
correct information would require to build the complete DepCache…
106
* [BUG] An installed package which changes the architecture from any to all
107
(and v.v.) shows up in the NEW packages section instead of UPGRADE.
108
* [TODO] Investigate the DepCache pseudo-package killer heuristic:
109
e.g. add more safety guards…
110
* [FIXME] a few corner cases/missing features marked as FIXME in the code
113
63
[0] https://wiki.ubuntu.com/MultiarchSpec
added
removed
README.MultiArch
