<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test/integration/test-multiarch-barbarian, branch 2.7.11</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.7.11</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.7.11'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2021-09-04T13:35:15Z</updated>
<entry>
<title>Barbarian M-A:allowed don't satisfy :any deps of other archs</title>
<updated>2021-09-04T13:35:15Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-09-04T00:22:24Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=79a675ddf3320bf640d130e592c86fefd1a460e1'/>
<id>urn:sha1:79a675ddf3320bf640d130e592c86fefd1a460e1</id>
<content type='text'>
What does a M-A:allowed package from non-native/non-foreign architecture
provide? If we look at M-A:foreign, such a package satisfies
dependencies within its own architecture, but not in other
architectures, so the same should apply to :any dependencies on
M-A:allowed packages, but we have a problem: While unqualified package
names are architecture-specific, the virtual package name qualified with
:any is not (see 3addaba1ff).

We could of course make it architecture-specific now, but that would
introduce many virtual packages for this relatively minor usecase and
would reintroduce a need for special display handling.

So, we pull a trick here: Barbarian M-A:allowed packages do not provide
the architecture-independent :any package anymore, but only a specific
one and every :any dependency from a barbarian package is rewritten to
an or-group of the specific and the independent :any package.

References: 3addaba1ff
</content>
</entry>
</feed>
