Bug#944190: release.debian.org: Allow britney to consider installability of dependencies of essential packages
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: britney
Tags: patch
Dear Release Team,
Whilst investigating why britney has not migrated src:elogind 241.3-1+debian1 to
bullseye, I discovered that the negative dependencies of the dependencies of
essential packages (Priority: required) are not actually tested for
installability[1].
The current implementation considers libsystemd0 as essential (by being a
dependency of apt, bsdutils et al.) and excludes libelogind0 from installability
testing as it is not co-installable with libsystemd0.
This behaviour is unchanged since the original version of the python
implementation of the installability tester[2] although it has been
reworked[3]. It appears to be a short-circuit bail out to avoid unnecessary
testing of packages that can't succeed. However, it precludes the consideration
of packages which might satisfy a dependency of an essential package through a
Provides.
The attached patch restricts the list of packages for which installability
testing is skipped just to packages which are not co-installable with any
Priority: required package. All other packages are tested normally for
installability.
The effect of this patch is that britney now successfully discovers that
libelogind0 can satisfy all the necessary dependencies and can migrate along
with the rest of src:elogind. The diff of HeidiResult with and without this
patch is also attached.
I think that my analysis is correct, particularly in respect of the original
intention of the handling of ess_never in _check_inst(). However, if I have
misunderstood the reasoning behind this or there are other unintended
consequences of the patch that I have not seen or envisaged, I am very happy to
work with you on a more suitable solution.
Thanks.
Mark
[1] https://salsa.debian.org/release-team/britney2/blob/master/britney2/installability/tester.py#L239
[2] https://salsa.debian.org/release-team/britney2/commit/7051d5b0e968936ebbd8a93040e9a2cbe9d3a7e1
[3] https://salsa.debian.org/release-team/britney2/commit/530db5d3f77da479078316aab3fee2389d58d172
-- System Information:
Debian Release: 8.11
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-10-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From d910a47311ba001976f90c5add8dcd0b518ccad7 Mon Sep 17 00:00:00 2001
From: Mark Hindley <mark@hindley.org.uk>
Date: Mon, 4 Nov 2019 12:35:57 +0000
Subject: [PATCH] Only block negative dependencies of essential packages
themselves.
The behaviour of _check_inst() to exclude consideration of packages in ess_never
originates in the python implementation of the installability tester in
2013 (7051d5b0e968936ebbd8a93040e9a2cbe9d3a7e1). It appears that the intention
is to avoid wasting cycles by testing the installability of packages that are
bound to fail.
Currently, ess_never is populated from packages that are in
universe.essential_packages (Priority: required) and their dependencies. This
treats the dependencies as if they are Priority: required themselves. However, a
dependency of an essential package could be satisfied by another package through
a Provides.
This patch ensures that only the negative dependencies of essential packages
themselves are included in ess_never. The effect of this is to allow all
packages that could provide the dependencies of an essential package be
considered for installability.
---
britney2/installability/tester.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/britney2/installability/tester.py b/britney2/installability/tester.py
index 5ac6ef2..8597f77 100644
--- a/britney2/installability/tester.py
+++ b/britney2/installability/tester.py
@@ -546,7 +546,8 @@ class InstallabilityTester(object):
break
for x in start:
- ess_never.update(universe.negative_dependencies_of(x))
+ if x in universe.essential_packages:
+ ess_never.update(universe.negative_dependencies_of(x))
self._cache_ess[arch] = (frozenset(start), frozenset(ess_never), frozenset(ess_choices))
return self._cache_ess[arch]
--
2.11.0
diff -c /tmp/britney/release.debian.org/britney/var/data-b2/output/HeidiResult /tmp/britney/release.debian.org/britney/var/data-b2/output_with_patch/HeidiResult
--- /tmp/britney/release.debian.org/britney/var/data-b2/output/HeidiResult 2019-11-04 12:51:41.000000000 +0000
+++ /tmp/britney/release.debian.org/britney/var/data-b2/output_with_patch/HeidiResult 2019-11-04 12:44:40.000000000 +0000
@@ -5032,7 +5032,7 @@
elki-dev 0.7.1-10.1 all science
elks-libc 0.16.17-3.3 all devel
elog 3.1.3-1-1 amd64 web
-elogind 239.3+20190131-1+debian1 amd64 admin
+elogind 241.3-1+debian1 amd64 admin
elpa-ac-rtags 2.34-1 all devel
elpa-ace-link 0.5.0-2 all lisp
elpa-ace-popup-menu 0.2.1-2 all lisp
@@ -18239,9 +18239,9 @@
libell-dev 0.25-1 amd64 libdevel
libell0 0.25-1 amd64 libs
libelocation1 1.21.1-5+b1 amd64 libs
-libelogind-dev 239.3+20190131-1+debian1 amd64 libdevel
-libelogind-dev-doc 239.3+20190131-1+debian1 all libdevel
-libelogind0 239.3+20190131-1+debian1 amd64 libs
+libelogind-dev 241.3-1+debian1 amd64 libdevel
+libelogind-dev-doc 241.3-1+debian1 all libdevel
+libelogind0 241.3-1+debian1 amd64 libs
libelpa-dev 2016.05.001-6+b1 amd64 libdevel
libelpa4 2016.05.001-6+b1 amd64 libs
libelput1 1.21.1-5+b1 amd64 libs
@@ -29506,7 +29506,7 @@
libpam-doc 1.3.1-5 all doc
libpam-duo 1.9.21-1.1 amd64 libs
libpam-dynalogin 1.0.0-3+b3 amd64 admin
-libpam-elogind 239.3+20190131-1+debian1 amd64 admin
+libpam-elogind 241.3-1+debian1 amd64 admin
libpam-encfs 0.1.4.4-12 amd64 admin
libpam-fprintd 0.8.1-1+b1 amd64 admin
libpam-freerdp2 2.0.0-2 amd64 admin
@@ -61933,7 +61933,7 @@
ell 0.25-1 source misc
elm-mode 0.20.3-2 source misc
elog 3.1.3-1-1 source misc
-elogind 239.3+20190131-1+debian1 source misc
+elogind 241.3-1+debian1 source misc
elpa 2016.05.001-6 source misc
elpa-migemo 1.9.2-2 source misc
elpa-rust-mode 0.3.0-3 source misc
Diff finished. Mon Nov 4 12:54:47 2019
Reply to: