Use the is_valid in "html"-method to determine whether to write "Valid
candidate" or not. This avoids the occasional:
* Valid candidate
* Invalidated by dependency
* Not considered
Signed-off-by: Niels Thykier <niels@thykier.net>
generate_package_list had the unintended side-effect of regenerating
self.excuses (up top of the original excuses).
Signed-off-by: Niels Thykier <niels@thykier.net>
Presumably there once was a reason for having a notion of "depth",
but these days only 3 "values" were given as "maxdepth":
* "easy" (for easy hint)
* 0 (for "main run" or in a "hint"-hint)
* -1 (for force-hint)
Signed-off-by: Niels Thykier <niels@thykier.net>
This allows britney to load a python2.7 variant of the C module when
run under python2.7.
Note for python3, we add "python3" rather than "python3.Y". This is
to reflect the include path in the python3 package in the archive.
Signed-off-by: Niels Thykier <niels@thykier.net>
"affected" is not allowed to contain duplicates. Since the current
method of removing any such duplicates is
affected = list(set(affected))
then the order of affected is not important.
As a side effect, make get_reverse_tree return a set instead of a
list as its return value is always inserted into affected.
Signed-off-by: Niels Thykier <niels@thykier.net>
Features like the auto-hinter, smooth-upgrades and removal of obsolete
source packages are now unconditionally enabled.
Signed-off-by: Niels Thykier <niels@thykier.net>
An "obsolete source" is one which produces no binaries. This situation
generally arises when all of the binaries which used to be produced by
the source package are now built by other sources.
Sooner or later such sources will probably be auto-crufted from unstable,
but there's no real reason to keep them in testing in the meantime.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
The initial packages of a hint are HintItems, whereas other packages
considered whilst processing the hint will be MigrationItems. In
either case, the version information is irrelevant during the output
of hint processing and only displaying it for some items is confusing
and distracting. Therefore, whilst processing a hint we always use
unversioned names.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Remove unused "excluded" argument from get_dependency_solvers and
excuse_unsat_deps. The argument was either always default or an empty
list.
Signed-off-by: Niels Thykier <niels@thykier.net>
Simply updating the include in britney-py.c, rebuilding and changing
the shebang of britney.py appears to be enough to make the switch in my
tests, so we just do that for now at least.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
If a hint item references unstable but its version is not correct for
that suite, we compare the version to the (t)pu version (if any) and
if a match is found update the item as if it had been explicitly
specified as applying to that suite originally.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
The feature is used to remove binaries left by smooth-updates and is not
exposed as an available hint type.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Commit 94071b16491e90d78605791a316141b58cc3c6fc excluded intra-source
dependencies from the determination as to whether a binary package was
eligible for smooth updates. Whilst this works in many cases, there
are situations where it breaks migration. For instance:
foo depends on libdropped1
libdropped1 depends on libdropped2
libdropped1 and libdropped2 are built from the same source; foo from
another source
libdropped2 is otherwise leaf in testing
In order to resolve this, we build a list of all packages which might
be eligible and filter out those which have reverse-dependencies outside
of their source package. For each remaining package, we consider it
eligible if its intra-source reverse-dependencies are within the list
of packages already determined to be eligible.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
The minimal set is comprised of only the first level of (reverse)
dependencies, before any further iterations of packages are added to
the set. In some cases, the result of the full iteration will contain
packages which cause problems when migrated but the minimal set,
although possibly a less optimal solution, may be able to migrate
successfully.
It is assumed that migrating the larger set of packages will be
preferred if possible, so minimal sets are tried later.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
