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>
Although it's technically correct, none of the other messages include closing
tags, and at least grep-excuses isn't prepared to deal with closing tags.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
In the unsat_deps case, it was used to update a field in the excuse,
but the field was never read anywhere.
Signed-off-by: Niels Thykier <niels@thykier.net>
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>
Adam D. Barratt
Niels Thykier
Cyril Brulebois
Mehdi Dogguy