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>
The new convenience HintItem class automatically sets the "this item contains
version information" flag when creating a new item.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
The use of MigrationItem allows us to centralise the parsing and splitting of
package names and architectures, avoiding duplication and simplifying a
number of conditions.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Rather than only considering pairs of packages, we start from a "leaf"
package (i.e. one with an excuse which declares no dependencies on
other packages' excuses) and recursively build a list of packages
which are the dependency or reverse dependency of a package already
in the list.
Any list which is a subset of another list is ignored and the remaining
items are then processed as "easy" hints.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Previously we could not reliably detect whether an excuse's dependency
from a source package to a binNMU was valid, as the excuse did not
contain sufficient information to determine the set of architecture(s)
on which the dependency existed.
By modifying the representation of the dependency list in the excuse to
include an architecture list we can walk the relationships in reverse
in order to sanity-check the source -> binNMU dependency.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
When considering an excuse for pkg1/arch, a dependency on either of
pkg2/source or pkg2/arch should be considered acceptable so long
as there is a corresponding excuse.
Dependencies from pkg1/source to pkg2/arch will still be considered
"impossible", as pkg1's excuse does not contain any information
regarding the architecture(s) on which its dependency to pkg2 exists.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
This allows the consideration of packages from proposed-updates to be
{dis,en}abled depending on whether the configuration file specifies
the path to the packages / sources files.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
This is most likely to be useful near the beginning of a release cycle,
when the versions of a package in stable and testing are the same and
the new version of the package is unable to migrate from unstable for
some reason.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
The permissions issues which led to the writing being disabled no longer
exist and not persisting the date list makes b2 unsuitable for use as a
primary implementation.
If a binary package being processed as part of a hint has moved source
packages, the installability checks for the new version of the binary
need to include the reverse-dependency information from the previous
version. In order to allow this, modify doop_source() to take an
optional list of undo information and iter_packages() to pass such
a list when processing hints.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
This reduces the number of ways in which we refer to uninstallable packages
to two. Those should probably be unified further to be consistent across
all parts of the code, but in the meantime this ensures that methods are
internally consistent in their terminology.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
The bug data has contained lists of bugs rather than simple counts for some
time now. Update the log messages to reflect this reality.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
When undoing the removal of a binary package by an "easy" hint, ensure
that the apt system is updated with the correct version of the package.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Given a package where the version in testing is arch:all and uninstallable
on architecture $arch and the version in unstable is arch:any but still
uninstallable on $arch, we need to ensure that installability checks add the
package to $arch's uninstallble list rather than just the list for
${arch}+all.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Rather than mapping "src:foo" to "foo" whilst building the bug hashes,
we store the src: bugs "as is" in the hash, and then include them in the
list of relevant bugs when building the list for a source package.
This avoids a situation where a bug filed against "src:foo" can impede
the migration of the binary package "foo", built from a different source
package.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Adam D. Barratt
Philipp Kern