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>
The initial packages of a hint are HintItems, whereas other packages
considered whilst processing the hint will be MigrationItems. In
either case, the version information is irrelevant during the output
of hint processing and only displaying it for some items is confusing
and distracting. Therefore, whilst processing a hint we always use
unversioned names.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Remove unused "excluded" argument from get_dependency_solvers and
excuse_unsat_deps. The argument was either always default or an empty
list.
Signed-off-by: Niels Thykier <niels@thykier.net>
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>
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>
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>
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>
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>
If new binary packages are removed from the system afer the original
packages have been re-introduced, a binary package which has moved
between source packages may be removed entirely. See Debian bug #624716
for more details.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
Starting with version 0.7.100, python-apt introduced a new API which
replaced several functions which created objects with real classes and
updated a number of method names to be PEP8 compliant.
get_full_tree may be passed an initial package which does not exist in the
target suite, for example because a package declares an obsolete conflict
on a second package which has subsequently been removed.
If the package was previously arch:all and uninstallable and has moved to
being architecture-dependent, becoming installable in the process, then it
will not be in the architecture-dependent uninstallability set; we
therefore should try removing it from that set.
When marking the reverse dependencies of each binary package as affected
by a sourceful update to testing, the reverse dependencies of those
packages are also affected, and so on.
This helps to avoid situations where the installability of immediate
reverse dependencies is unchanged, but that of other packages in the
dependency chain is altered, for example where alternative dependencies
are used.
See Debian bug #614249 for further details.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
This extends the scope of commit 5e3a245759
to include cases where the tpu binNMUs are explicitly included in an "easy"
or "hint" rather than processed as part of the main run.
Signed-off-by: Adam D. Barratt <adam@adam-barratt.org.uk>
When undoing the addition to the result set of a binNMU from tpu, the package
name from the hint will end in ${arch}_tpu, not ${arch}, so we should check
for both cases. At the same time, reverse the sense of the associated test
to make the logic more obvious.
Niels Thykier
Adam D. Barratt
Mehdi Dogguy
Julien Cristau
Philipp Kern