If we have this situation
- Binary in target taken over by new source
- Not cleaned up yet
- New source updated in source suite
We can have *three* copies of a source package visible to britney at
once. Handle this case by recording the source package a pkgid was seen
in before, and trying to remove from that and the current source.
When the architecture are read from the Release file, they are not
defined in the config file.
Adding 'all' as an architecture will not give the correct result. To
avoid confusion, explicitly check for this and error out if it is added.
Adding a source parameter to the SourcePackage allow finding the source
the object is referring to, so that parameter doesn't have to be passed
along separately.
Signed-off-by: Ivo De Decker <ivodd@debian.org>
The spec for Release files says that (at least) one of "Suite" and
"Codename" will be defined. This implies that "Suite" is optional
in some cases and SuiteLoader now correctly falls back to using
"Codename" in that case.
Closes: https://bugs.debian.org/942104
Signed-off-by: Niels Thykier <niels@thykier.net>
The recent code changes made use remove from the "binaries" field in
SourcePackages. Lists are not particularly optimized for this kind
of removal and we have a few source packages with a lot of binary
packages (e.g. libreoffice, gcc-X-cross{,-ports}) that might trip
poor performance.
Signed-off-by: Niels Thykier <niels@thykier.net>
In Debian, the same override is applied to both suites and they are
always consistent. It's not the case in Kali, we keep the value from
Debian when we import the package in britney's source distribution, but
if the same version is already present in the target distribution, it
keeps its original section (dating back to its initial import). In those
situations, the code will fail with an error like this one:
E: [2018-12-28T19:57:57+0000] - Mismatch found coinor-libdylp0 1.6.0-1.1 amd64 differs
I: [2018-12-28T19:57:57+0000] - ... section libs != science
[...]
ValueError: Inconsistent / Unsupported data set
Commit 7efa865a04892b94a0ef18b2e611f210a6963925 which was supposed to
move code around introduced the check on this field. Prior to this, the
section was not checked. Since the section only has an impact on which
packages take part to the smooth updates feature, the impact of such a
mismatch is negligible so I simply dropped that check.
