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>
The primary difference between the parsing / output of excuses for *pu
and unstable unblocks is the messages displayed. We can therefore remove
some duplication by having the same code handle both, outputting the
appropriate message.
Where a *pu package is also the subject of a "block" (most likely during
a freeze) we only supply the "needs approval" or "approved" message;
previously both "needs approval" and "not touching due to block" were
output, which is redundant. We ensure that there is always a dummy
"block" hint for *pu packages to provide the "needs approval" behaviour.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
An "approve" hint is effectively an unblock for tpu packages and britney
is already quiite happy to parse "unblock $pkg/$tpuversion".
We allow the old name to be used for compatibility and replace it with
"unblock" internally.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
A dependency on an arch-specific package which is not a valid candidate
should lead to the depending package not being a candidate.
For now we ensure that the generated excuses output remains the same,
so that we don't have to wait for consumers to adapt to a new format.
Changing the output format should be revisited at a later point.
See Debian bug #693068.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
The code using the variables was refactored in 694d614b. As a result
they were still set in iter_packages() but never subsequently used.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Previously a package which became obsolete during a run would not be
automatically removed until the next run. This was due to the fact that
sources[][BINARIES] is not updated during the run. Instead, we build a
list of source packages which produce at least one binary and then
remove any packages not in that list.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Setting SMOOTH_UPDATES to a string which is neither a valid section
name (nor the magic string "ALL") should allow removal of old libraries
to continue without any new smooth updated libraries being accepted.
An empty SMOOTH_UPDATES would also stop removals from occurring.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
"not force and not earlyabort" simplifies to "not earlyabort" rather
than "not force", as an easy hint would set "earlyabort" but not
"force".
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
All callers of get_reverse_tree compute the same modification of its
return value, so move that computation into get_reverse_tree.
Signed-off-by: Niels Thykier <niels@thykier.net>
When processing a hint of the form "easy pkgX libX" where libX would be
a candidate for smooth updates because pkgX/testing depends on it but
pkgX/unstable does not, and there are no other reverse dependencies,
the old binary from libX can simply be dropped straight away.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
The only test currently implemented is to ensure that any prospective
hint contains at least one item beyond the hint name. This prevents
lines in a hint file consisting simply of e.g. "easy" being added to
the hint list and causing later processing to abort with an error.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
This causes Multi-arch dependencies like "pkg:i386" to show up as
unsatisfiable in excuses.
Previously, the dependency would be checked on the wrong architecture
(if available) and cause the package to become a valid candidate. The
package would still be prevent from migrating as the installability
checker does not know of the "pkg:i386" package.
Signed-off-by: Niels Thykier <niels@thykier.net>
Adam D. Barratt
Niels Thykier
Cyril Brulebois