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>
Changing the suite requires update the item's canonical names, as these
need to reflect the new suite.
The property() function only applies to new-style classes, so we also
need to update MigrationItem to be new-style.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
This allows us to re-canonicalise the item's name if any of the item's
properties are altered without updating its name.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
This will work for "single package" hints, but should be extended to
consider "easy foo/1 bar/1" and "easy bar/1 foo/1" to be equivalent.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
This relies on the caller supplying a list of valid architectures, and
assumes that none of the list entries are also valid version strings.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Although multiple formats of item name are accepted (e.g.
$pkg_$suite/$arch and $pkg/$arch_$suite), for compatibility and ease of
parsing by clients the output format is standardised.
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 94071b1649 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>
Adam D. Barratt
Julien Cristau
Niels Thykier