diff options
author | David Kalnischkies <david@kalnischkies.de> | 2015-04-22 12:06:40 +0200 |
---|---|---|
committer | David Kalnischkies <david@kalnischkies.de> | 2015-04-22 12:40:51 +0200 |
commit | 6c9937da76b9155d166092b9dda22d06200510c1 (patch) | |
tree | ab4693d386ba9f143d5feabc4d064e404d95c707 /test/integration/test-unpack-different-version-unpacked | |
parent | ae37ab01c4657fc2ae32cabb4f96f5f7e5b551d4 (diff) |
remove "first package seen is native package" assumption
The fix for #777760 causes packages of foreign (and the native)
architectures, to be created correctly, but invalidates (like the
previously existing, but policy-forbidden architecture-less packages
we had to support for some upgrade scenarios) the assumption that the
first (and only) package in the cache for a single architecture system
must be the package for the native architecture (as, where should the
other architectures come from, right? Wrong.).
Depending on the order of parsing sources more or less packages can be
effected by this. The effects are strange (for apt it mostly effects
simulation/debug output, but also apt-mark on these specific packages),
which complicates debugging, but relatively harmless if understood as
most actions do not need direct named access to packages.
The problem is fixed by removing the single-arch special casing in the
paths who had them (Cache.FindPkg), so they use the same code as
multi-arch systems, which use them as a wrapper for Grp.FindPkg.
Note that single-arch system code was using Grp.FindPkg before as well
if a Grp structure was handily available, so we don't introduce new
untested code here: We remove more brittle special cases which are less
tested instead (this was planed to be done for Stretch anyhow).
Note further that the method with the assumption itself isn't fixed. As
it is a private method I opted for declaring it deprecated instead and
remove all its call positions. As it is private no-one can call this
method legally (thanks to how c++ works by default its still an exported
symbol through) and fixing it basically means reimplementing code we
already have in Grp.FindPkg.
Removing rather than fixing seems hence like a good solution.
Closes: 782777
Thanks: Axel Beckert for testing
Diffstat (limited to 'test/integration/test-unpack-different-version-unpacked')
0 files changed, 0 insertions, 0 deletions