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>
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>
Each property returns the value of the corresponding property for the first
entry in the package list; this is a handy short-cut for hints where there
will only ever be one package in the list (e.g. "age-days", "unblock").
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
string.split()'s second argument specifies the maximum number of times
the string should be split, not the maximum number of elements in the
result.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
In order to make a number of the changes required for the migration simpler,
we also complete the previous migration to using {Hint,Migration}Item rather
than passing around strings representing packages and converting between
the two forms in several places.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
In order to provide the support, items may now be tested for equality
and hashed. Two items are considered equal if they have the same
unversioned name (and version, if appropriate); hashing is based on
a tuple hash of the name and version.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
The major change is reversing the order of three-part item names (i.e.
binNMUs with version information included) to use the more traditional
ordering of <src>/<arch>/<ver>.
Even if an instance is marked as versionned, passing a non-versionned
source package name should not cause a traceback.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
This can be used to retrieve the version information from a versionned hint;
for unversionned hints, it is effectively a synonym for "name".
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
These classes encapsulate information about individual hints, with
HintCollection providing a convenient wrapper around a set of hints.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>