summaryrefslogtreecommitdiff
path: root/buildlib/python.mak
diff options
context:
space:
mode:
authorDavid Kalnischkies <david@kalnischkies.de>2015-04-22 12:06:40 +0200
committerDavid Kalnischkies <david@kalnischkies.de>2015-04-22 12:40:51 +0200
commit6c9937da76b9155d166092b9dda22d06200510c1 (patch)
treeab4693d386ba9f143d5feabc4d064e404d95c707 /buildlib/python.mak
parentae37ab01c4657fc2ae32cabb4f96f5f7e5b551d4 (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 'buildlib/python.mak')
0 files changed, 0 insertions, 0 deletions