In 'partial source' mode, which we use in Ubuntu, we merge the target
(release pocket) with the source (proposed), so that proposed-migration
has a view of the complete state of the archive when it is migrating.
This merging must not be done when a package has been built in the
source suite. If it is done incorrectly, proposed-migration will see the
previous binary packages as existing when they should not.
We have code to handle this already, but it's wrong in the case of
arch:all binaries. This comes up in two ways
- If a source package builds *only* arch:all binaries, it is not
expected that builds will be created on arches other than the one
which builds arch:all packages (amd64 currently). If that is built
then the package is complete, we shouldn't merge any old binaries
such as dropped arch:all ones from the target.
- Relatedly, if other non-arch-all packages exist, an arch:all package
isn't an indication that a build has taken place on other arches
than the all buildd arch.
Fixing both of these stops old binaries being merged into a new source
when it's been built and arch:all packages are involved.
udebs do not have symbol versioned shlibdeps, thus it means that when
there is glibc in proposed, any packages built in proposed get a udeb
depends on the strictly higher version of glibc in proposed. This
leads to entaglement of the $world with glibc transition. Similar
story with glib, openssl, etc.
By setting the new configuration option to HAS_UDEBS = no, one can
make suiteloader not look at udebs, and thus use britney even when
installability of udebs is not required.
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 7efa865a04 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.
Iain Lane
Dimitri John Ledkov
Iain Lane
Colin Watson
Ivo De Decker
Niels Thykier
Paul Gevers
Raphaël Hertzog