[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#679829: marked as done (britney: breakage of packages on removal of virtual packages)



Your message dated Tue, 25 Dec 2012 20:05:45 +0000
with message-id <7312326435e8eb7bd6b66b50a25581d1@mail.adsl.funky-badger.org>
and subject line Re: Bug#679829: britney: breakage of packages on removal of virtual packages
has caused the Debian Bug report #679829,
regarding britney: breakage of packages on removal of virtual packages
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
679829: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679829
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: patch
User: release.debian.org@packages.debian.org
Usertags: britney

Hi,

As mentioned on IRC, I believe I found a bug in Britney2.  As far as I
can tell the bug is only triggered in certain "special" cases.  The
conditions are:

 * There must be a real package "R" and a package "V" in testing.
 * "V" must provide "R".
 * Another package "P" must have an unversioned dependency on "R"
   and "R" must be unable to satisfy the relation.  (e.g. "R" can
   conflict with "P").
 * Britney must attempt to remove "V".

The bug happens because Britney (in register_reverse) does not record
providing packages in a package's RDEPENDS if there is a real package
for that given dependency.  In the example above, Britney will think
that "V" has no rdepends.

This bug can be seen in the test
"basic-uninstallable-deep-breaks-rm-virtual" (in t-unsupported) in
britney2-tests.  Once I have the bug number I will push a minimal test
for this case as well.

~Niels
>From 2b00f6c27c7240546487880c8ffdd39b3a92884b Mon Sep 17 00:00:00 2001
From: Niels Thykier <niels@thykier.net>
Date: Sun, 1 Jul 2012 23:52:48 +0200
Subject: [PATCH] Always include providers of virtual packages in rdepends

Signed-off-by: Niels Thykier <niels@thykier.net>
---
 britney.py |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/britney.py b/britney.py
index 5205f64..c456460 100755
--- a/britney.py
+++ b/britney.py
@@ -600,8 +600,8 @@ class Britney(object):
                 # register real packages
                 if a[0] in packages and (not check_doubles or pkg not in packages[a[0]][RDEPENDS]):
                     packages[a[0]][RDEPENDS].append(pkg)
-                # register packages which provide a virtual package
-                elif a[0] in provides:
+                # also register packages which provide a virtual package (if any)
+                if a[0] in provides:
                     for i in provides.get(a[0]):
                         if i not in packages: continue
                         if not check_doubles or pkg not in packages[i][RDEPENDS]:
-- 
1.7.10


--- End Message ---
--- Begin Message ---
On 01.07.2012 22:28, Niels Thykier wrote:
On 2012-07-02 00:19, Adam D. Barratt wrote:
On Mon, 2012-07-02 at 00:12 +0200, Niels Thykier wrote:
--- a/britney.py
+++ b/britney.py
@@ -600,8 +600,8 @@ class Britney(object):
                 # register real packages
if a[0] in packages and (not check_doubles or pkg not in packages[a[0]][RDEPENDS]):
                     packages[a[0]][RDEPENDS].append(pkg)
- # register packages which provide a virtual package
-                elif a[0] in provides:
+ # also register packages which provide a virtual package (if any)
+                if a[0] in provides:
                     for i in provides.get(a[0]):
                         if i not in packages: continue
if not check_doubles or pkg not in packages[i][RDEPENDS]:

Hmmm, does the rconflicts block immediately below not need the same
change?
[...]
Seems reasonable.  I am not able to produce a test for that case.
However, that may just be a lack of imagination on my part, so here is
an updated patch.

Applied, thanks.

Regards,

Adam

--- End Message ---

Reply to: