Based on Colin Watson's code to do the same from the "britney2-ubuntu"
repository[1] revision 306, 308 and 309.
Notable differences include:
* output include version of source package being removed
* output prefix removals with a "-" (otherwise it would be identical to
a upgrade/new source with the change above).
[1] http://bazaar.launchpad.net/~ubuntu-release/britney/britney2-ubuntu/revision/306
Signed-off-by: Niels Thykier <niels@thykier.net>
This introduces a new variable HINTSDIR, which overrides the location of the
Hints dir (normally it is read from the UNSTABLE dir).
Please note that this is the location of the dir that contains the Hints dir.
Signed-off-by: Niels Thykier <niels@thykier.net>
This introduces a new variable OUTPUTDIR, which overrides the location where
the new dates file is written. This allow to run britney against a read-only
copy of the data.
Signed-off-by: Niels Thykier <niels@thykier.net>
Set the default to maxint until we've read something.
Reported-by: Ivo De Decker <ivo.dedecker@ugent.be>
Signed-off-by: Julien Cristau <jcristau@debian.org>
The new Installability Tester (IT) module replaces the remaining
C-parts. Unlike C-implementation, it does not give up and emit an
"AIEEE" half-way through.
In order to determine installability, it uses two sets "musts" and
"never". As the names suggest, the sets represents the packages that
must be (co-)installable with the package being tested and those that
can never be co-installable. For a package to be installable, "musts"
and "never" have remain disjoint.
These sets are also used to reduce the number of alternatives that are
available to satisfy a given dependency. When these sets are unable
to remove the choice completely, the new IT defers the choice to later.
This occasionally reduces backtracking as a later package may conflict
or unconditionally depend on one of the remaining alternatives.
Signed-off-by: Niels Thykier <niels@thykier.net>
We stopped populating the element with real data some time ago, it's
time to drop it entirely.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Multiarch adds a Depends: foo:any syntax, permitted only if the
target of the dependency is "Multi-Arch: allowed". This has
been supported by dpkg and apt for some time and is now safe to
use in unstable.
[Adam D. Barratt: adjusted to use consts.py]
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
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>
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>