[pacman-dev] [PATCH] New reason001.py pactest
From d0caed6bee5fec36f3239d4886db9323ffc64db9 Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba@bibl.u-szeged.hu> Date: Fri, 11 Jan 2008 21:51:50 +0100 Subject: [PATCH] New reason001.py pactest This pactest demonstrates that we should copy the reason between the to-be-replaced and replaced packages Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu> --- pactest/tests/reason001.py | 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-) create mode 100644 pactest/tests/reason001.py diff --git a/pactest/tests/reason001.py b/pactest/tests/reason001.py new file mode 100644 index 0000000..d0e4650 --- /dev/null +++ b/pactest/tests/reason001.py @@ -0,0 +1,16 @@ +self.description = "Copy reason (to-be-replaced -> replacement)" + +sp = pmpkg("libfoo-ng") +sp.replaces = [ "libfoo" ] +self.addpkg2db("sync", sp) + +lp = pmpkg("libfoo") +lp.reason = 1 +self.addpkg2db("local", lp) + +self.args = "-Su" + +self.addrule("PACMAN_RETCODE=0") +self.addrule("!PKG_EXIST=libfoo") +self.addrule("PKG_EXIST=libfoo-ng") +self.addrule("PKG_REASON=libfoo-ng|1") -- 1.5.3.7
On Jan 11, 2008 2:53 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
From d0caed6bee5fec36f3239d4886db9323ffc64db9 Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba@bibl.u-szeged.hu> Date: Fri, 11 Jan 2008 21:51:50 +0100 Subject: [PATCH] New reason001.py pactest
This pactest demonstrates that we should copy the reason between the to-be-replaced and replaced packages
Makes sense. Any reason why you wouldn't ever want to do this? I can think of one such scenario, not sure if it is handled or not. Installed: pkg1 (explicit) pkg2 (as dep) To be installed: pkg1 (replaces pkg2 because it includes its functionality) pkg1 should stay explicit. Along the same lines, if the reasons were reversed, we should still stay explicit, no? -Dan
On Jan 11, 2008 2:53 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
From d0caed6bee5fec36f3239d4886db9323ffc64db9 Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba@bibl.u-szeged.hu> Date: Fri, 11 Jan 2008 21:51:50 +0100 Subject: [PATCH] New reason001.py pactest
This pactest demonstrates that we should copy the reason between the to-be-replaced and replaced packages
Makes sense. Any reason why you wouldn't ever want to do this? I can think of one such scenario, not sure if it is handled or not.
Installed: pkg1 (explicit) pkg2 (as dep)
To be installed: pkg1 (replaces pkg2 because it includes its functionality)
pkg1 should stay explicit.
Along the same lines, if the reasons were reversed, we should still stay explicit, no?
-Dan
Yes, this case is handled properly. Whatever is set by sync.c, add.c overrides it if the package is already installed (except --asdeps is added). So in your case pkg1 will be _upgraded_ as explicit. One more thing (edge case): In my not-working (:-)) patch I preferred explicit over depend if foo replaces more than one packages and some of them explicit, some of them dependency. Bye
From d0caed6bee5fec36f3239d4886db9323ffc64db9 Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba@bibl.u-szeged.hu> Date: Fri, 11 Jan 2008 21:51:50 +0100 Subject: [PATCH] New reason001.py pactest
This pactest demonstrates that we should copy the reason between the to-be-replaced and replaced packages
Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu> --- pactest/tests/reason001.py | 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-) create mode 100644 pactest/tests/reason001.py
diff --git a/pactest/tests/reason001.py b/pactest/tests/reason001.py new file mode 100644 index 0000000..d0e4650 --- /dev/null +++ b/pactest/tests/reason001.py @@ -0,0 +1,16 @@ +self.description = "Copy reason (to-be-replaced -> replacement)" + +sp = pmpkg("libfoo-ng") +sp.replaces = [ "libfoo" ] +self.addpkg2db("sync", sp) + +lp = pmpkg("libfoo") +lp.reason = 1 +self.addpkg2db("local", lp) + +self.args = "-Su" + +self.addrule("PACMAN_RETCODE=0") +self.addrule("!PKG_EXIST=libfoo") +self.addrule("PKG_EXIST=libfoo-ng") +self.addrule("PKG_REASON=libfoo-ng|1")
Well, I've tried to fix/implement this, with no success :-( ... I'm pretty sure now that we cannot do it ("cleanly") without modifying the pmsyncpkg_t struct (see also sync044.py) Bye
participants (2)
-
Dan McGee
-
Nagy Gabor