As HintItem is now redundant, also replace it with a new class -
UnversionnedMigrationItem - and migrate users of the classes to use
the new versions.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
This function allows a textual representation of a package (e.g.
"foo/amd64") to be convered to a HintItem().
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Where possible, avoid creating a list only to discard immediately
afterwards. Example:
"""
for x in sorted([x for x in ...]):
...
"""
Creates a list, passes it to sorted, which generates a new list and
sorts that copy. Since sorted accepts an iterable, we can avoid the
"inner" list and just pass it a generator expression instead.
Signed-off-by: Niels Thykier <niels@thykier.net>
By moving the package loop inside register_reverses, it will be
invoked a lot less (reducing the overhead of invoking functions).
Signed-off-by: Niels Thykier <niels@thykier.net>
Beside some "minor differences" they were computing the same "tree"
(read: "graph"), so merge them into one (get_reverse_tree) and
properly document return value and special cases.
Signed-off-by: Niels Thykier <niels@thykier.net>
Rewrite the arguments of find_upgraded_binaries to not use an instance
of MigrationItem. We want to call it at a time where we have not
created MigrationItems yet.
Signed-off-by: Niels Thykier <niels@thykier.net>
A removal hint will generate both source and per-arch excuses if the
version of the source package differs between testing and unstable. If
the source versions are the same then only the per-arch excuses will
be generated.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
In rare cases with hints with overlapping virtual packages provided by
different sources, this can make a difference.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
If there are multiple versions of an arch:all package in unstable (due
to outdated or no longer built arch:any packages) then only one of them
should be recorded in the list of binary packages built from the source
package. Otherwise we may try and remove the binary package from various
lists multiple times, leading to crashes.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Given a source which provides two packages and has different versions
in testing and unstable, binNMUs in unstable corresponding to the
older source version should not be considered as migration candidates.
For example:
testing
-------
source 1
bin 1 arch1
bin 1 arch2
unstable
--------
source 2
bin 2 arch1
bin 1+b1 arch2
The binary migration on arch2 should not be considered a candidate.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Although this should never happen, rather than crashing if one of the
versions is none, simply indicate that they are unequal.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Although this isn't an issue during normal runs, the excuses might be
built multiple times during a hint-tester run and should not accumulate
during the run.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
For those hints which don't cause an immediate run (i.e. other than
easy, hint and force-hint), re-build the excuses after adding the
hint so that the actions are accounted for in later hints.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
A binNMU does not rebuild architecture:all packages. For migrations via
unstable this is not a problem as the packages corresponding to the
source upload are still present. However, for *pu migrations, the set of
packages considered only includes architecture-specific packages. In
order to avoid installability issues with packages in testing which
depend on the arch:all packages, we leave the existing arch:all packages
in testing and only consider the arch-specific packages for migration.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
The test only needs to consider whether any binaries exist on a given
arch, not how many of them there are (or indeed which binaries they are)
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
When checking whether a tpu source has built on a particular arch, we
should only consider binaries produced by the latest version of the
source package in tpu.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Originally when binNMUs for packages in testing were scheduled, the
binaries would be installed into tpu with no accompanying source. This
allowed the "removed binary" portions of should_upgrade_srcarch() to be
skipped (as britney had generated a faux source record).
dak now adds the source package to tpu in such cases which lead to the
"removed binary" checks being applied to binNMUs in tpu with potentially
destructive consequences. For example, if a package with amd64 and i386
binaries in testing were binNMUed on just amd64, britney would notice
that there were no i386 binaries in tpu and subsequently remove the i386
binaries from testing as well.
In order to resolve this, we skip the check for removed binaries when
building excuses for a binary-only migration via *pu.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Adam D. Barratt
Niels Thykier
Colin Watson