[pacman-dev] CVS update of pacman-lib/pactest (pmenv.py tests/upgrade056.py)
Date: Tuesday, February 27, 2007 @ 14:44:45 Author: dan Path: /home/cvs-pacman/pacman-lib/pactest Added: tests/upgrade056.py (1.1) Modified: pmenv.py (1.6 -> 1.7) * Added another test- I believe it is a possible situation and one we need to deal with. Currently, libalpm with AND without Nagy's patch fails it. * Slight spacing update to pmenv.py. ---------------------+ pmenv.py | 2 +- tests/upgrade056.py | 24 ++++++++++++++++++++++++ 2 files changed, 25 insertions(+), 1 deletion(-) Index: pacman-lib/pactest/pmenv.py diff -u pacman-lib/pactest/pmenv.py:1.6 pacman-lib/pactest/pmenv.py:1.7 --- pacman-lib/pactest/pmenv.py:1.6 Mon Feb 26 03:19:02 2007 +++ pacman-lib/pactest/pmenv.py Tue Feb 27 14:44:45 2007 @@ -107,7 +107,7 @@ print "[PASSED]", else: print "[FAILED]", - print "%s Rules:OK = %2u FAIL = %2u SKIP = %2u" \ + print "%s Rules: OK = %2u FAIL = %2u SKIP = %2u" \ % (test.testname.ljust(32), success, fail, rules - (success + fail)) print "=========="*8 Index: pacman-lib/pactest/tests/upgrade056.py diff -u /dev/null pacman-lib/pactest/tests/upgrade056.py:1.1 --- /dev/null Tue Feb 27 14:44:45 2007 +++ pacman-lib/pactest/tests/upgrade056.py Tue Feb 27 14:44:45 2007 @@ -0,0 +1,24 @@ +self.description = "Upgrade a package that removes a provide but another package still does" + +lp1 = pmpkg("pkg1") +lp1.depends = ["imaginary"] +self.addpkg2db("local", lp1) + +lp2 = pmpkg("pkg2") +lp2.provides = ["imaginary"] +lp2.requiredby = [ "pkg1" ] +self.addpkg2db("local", lp2) + +lp3 = pmpkg("pkg3") +lp3.provides = ["imaginary"] +self.addpkg2db("local", lp3) + +p = pmpkg("pkg2", "1.0-2") +self.addpkg(p) + +self.args = "-U %s" % p.filename() + +self.addrule("PACMAN_RETCODE=0") +self.addrule("PKG_EXIST=pkg1") +self.addrule("PKG_VERSION=pkg2|1.0-2") +self.addrule("PKG_EXIST=pkg3")
On 2/27/07, Dan McGee <dan@archlinux.org> wrote:
+self.description = "Upgrade a package that removes a provide but another package still does"
Good call. This one may be important, as it might (should?) also cover the case of: pkgA provides=('foo') pkgB depends=('foo') pkgC provides=('foo') conflicts=('pkgA') local => pkgA, pkgB pacman -S pkgC (remove pkgA, install pkgC) unless this is already covered somewhere else... I can look later.
On 2/27/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 2/27/07, Dan McGee <dan@archlinux.org> wrote:
+self.description = "Upgrade a package that removes a provide but another package still does"
Good call. This one may be important, as it might (should?) also cover the case of:
pkgA provides=('foo') pkgB depends=('foo') pkgC provides=('foo') conflicts=('pkgA')
local => pkgA, pkgB pacman -S pkgC (remove pkgA, install pkgC)
unless this is already covered somewhere else... I can look later.
Sync might handle it differently, as they are still divergent in some areas. I have been adding all these tests as upgrade operations, but it would be worthwhile for now to have tests to be done in both areas- sync and upgrade. I can throw the above together real quick into a test case and see how it goes. -Dan
On 2/27/07, Dan McGee <dpmcgee@gmail.com> wrote:
On 2/27/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 2/27/07, Dan McGee <dan@archlinux.org> wrote:
+self.description = "Upgrade a package that removes a provide but another package still does"
Good call. This one may be important, as it might (should?) also cover the case of:
pkgA provides=('foo') pkgB depends=('foo') pkgC provides=('foo') conflicts=('pkgA')
local => pkgA, pkgB pacman -S pkgC (remove pkgA, install pkgC)
unless this is already covered somewhere else... I can look later.
I can throw the above together real quick into a test case and see how it goes.
Well- your test passed with flying colors! (sync896 now). However, I figured this was a false positive, and looking at the debug log confirmed it. So I added sync895 as well, which fails bad now, as it performs the upgrade even though it breaks dependencies. It is exactly as you said above, however, the new package (pkgC) does NOT provide foo, and thus should fail. It doesn't. -Dan
Hi! My patch won't fix it neither. I think packages with the same provide should be mutual. -R doesn't work neither. Pacman doesn't deal with multiple provides at all. Bye, Nagy Gabor
On Tue, 27 Feb 2007 22:05:01 +0100 Nagy Gabor <ngaba@petra.hos.u-szeged.hu> wrote:
Hi! My patch won't fix it neither. I think packages with the same provide should be mutual. -R doesn't work neither. Pacman doesn't deal with multiple provides at all. Bye, Nagy Gabor
While pacman may be broken in this respect, I disagree that provides means conflicts. The provides option should mean, "is equivalent to", and the conflicts option should mean, "can't be installed at the same time as". That way, when you combine them, they mean, "X is equivalent to Y but can't be installed at the same time as Y". Keep the options seperate. Jason
On 2/27/07, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> wrote:
I think packages with the same provide should be mutual.
No, this is not correct. Let's imagine the grand scheme here: apache provides=(webserver) lighttpd provides=(webserver) thttpd provides=(webserver) phpmyadmin depends=(webserver) No one would argue that the above is totally logical. However, you are suggesting that apache and lighttpd cannot be installed on that same machine (because of the 'provides' entry). That's not a good idea.
Pacman doesn't deal with multiple provides at all.
Sure it does. I've changed quite a few functions to deal with multiple provides, such as the -Rc functionality. Why do you think alpm_db_whatprovides() returns a list instead of a single package?
Hi! OK. Your example is correct. However the correct managing of multiple provides is difficult. And this will cause more slowdown of pacman (but see my suggestion: collect all provider packages' symlink in local/.providers for example). And what I say that now the _correct_ multiple providing in pacman is missing. Some things: -if you remove a package and a dependency would broke, you must check if there is another provider package of that dependency installed (slow now), the same for update (but this is rare: update056.py) -when you want to -S a provided_package, undefined provider will be installed (an ask from user would be nice) -anyway, there is only one type of provide-dependencies (however, a "virtual" version number may not be useless: webserver 2.0 for example) -and what about the fact that if provide allowed, between 2 packages more than one dependencies can happen (this is not programmed to pacman neither; at least what in the parts what I saw)? -again, my main problem is the efficiency: now there are direct dependencies which can be checked very fast, and the provide-dependency which if you want to check, you must read the whole database to find providers. Yes, I see, that provide is needed, because you have to be able to define a "set of packages" somehow. What I say, that these sets of packages should be store explicitly (not only implicitly). There is not much difference between groups and providers from this point of view. Nagy Gabor
On 2/27/07, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> wrote:
OK. Your example is correct. However the correct managing of multiple provides is difficult. And this will cause more slowdown of pacman (but see my suggestion: collect all provider packages' symlink in local/.providers for example).
This is a conflict of design and implementation. By design, the current way provide handling works is ideal. The "slowdown" is purely related to the actual backend, which will be revamped in the future. Trying to re-structure the way provides work due to slowdown is attacking the problem from the wrong angle. The correct approach here is to reformat the backend database, which we plan on doing real soon.
-when you want to -S a provided_package, undefined provider will be installed (an ask from user would be nice)
Yes, asking a user which package to install is probably ideal, but this is not implemented yet. Right now, I believe it choses the first it finds, which is the same way pacman 2 currently works. That is, of course, unless the provision is already satisfied.
-anyway, there is only one type of provide-dependencies (however, a "virtual" version number may not be useless: webserver 2.0 for example)
That doesn't really make sense. What about a virtual "browser" package covering firefox/opera/galeon/knoqueror? What would "browser 3.0" be? Either way, provided packages are string-matched exactly, so "webserver2" does not match "webserver".
-and what about the fact that if provide allowed, between 2 packages more than one dependencies can happen (this is not programmed to pacman neither; at least what in the parts what I saw)?
I don't understand. Are you saying that forced resolution of a provides=() package can cause unnecessary dependencies?
-again, my main problem is the efficiency
See my first point.
There is not much difference between groups and providers from this point of view.
Absolutely there is. A group is a logical set of packages that tend to be considered one large set (gnome, vim-plugins, kde, etc). A group implies the content is generall install all together. A provision, on the other hand, indicates that the given package provides a specific feature, which is satisfied as long as a single package providing that feature is present.
I don't understand. What I say, that if provide is allowed it's possible that if foo1 depends on foo2, then more than one dependencies may exists between
Absolutely there is. I know what are the differences in package management, I said "from this
Hi! 1. I'm saying that nothing is wrong with the current backend, just some needed properties of the database is not stored explicitly, that's why you have to find it with brute force (by reading the whole database)! You say that many small files are bad, but that's not true; you can think of it, that you have extra pointers (directory names) which points to the needed data! My "solution" is as safe as possible and as compatible with the older versions as possible. One more word about speed: it's nonsense that dpkg & apt-* is faster on a 386 than pacman on a P4. I'm _sure_ that if these really small things would be implemented, pacman would be faster (see above). 2. OK. I understand, that non-mutual provide is needed, I'm just lazy :-) And the pathological examples makes the life difficult :-) (Look, I haven't seen two provider package which aren't mutual; and none of my reported bugs was found earlier etc. etc.) them: for example foo1 depends on foo3 too, and foo2 provides foo3. The current pacman doesn't count with this (this is rare, I know.) point of view": they are just sets (for different purposes), they should be managed similarly (in programming; internally) Nagy Gabor
On 2/27/07, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> wrote:
Hi!
OK. Your example is correct. However the correct managing of multiple provides is difficult. And this will cause more slowdown of pacman
We value correctness over speed. These operations are not that slow once the DB is read- they are actually quite fast. The longest operation done by pacman is unpacking the archives, by quite a long shot. We need to focus on optimizing the 20% of the code that is 80% of the time, not the other way around.
And what I say that now the _correct_ multiple providing in pacman is missing.
We're aware, thus the failed test. It doesn't mean it shouldn't be added. It just hasn't come up before (and/or been tested well before).
Some things: -if you remove a package and a dependency would broke, you must check if there is another provider package of that dependency installed (slow now), the same for update (but this is rare: update056.py)
Like I said above, this shouldn't be too slow. However, Aaron and I have both come up with some data structure ideas that we may want to toss around to possibly speed things like this up.
-when you want to -S a provided_package, undefined provider will be installed (an ask from user would be nice)
I think you are saying the user should be prompted- I don't believe pacman ever proceeds without confirmation if it pulls in dependencies, correct me if I am wrong, so they could at least see if the provide they wanted was there. We could later add some functionality to pick a particular "provide" if there were multiple available.
-anyway, there is only one type of provide-dependencies (however, a "virtual" version number may not be useless: webserver 2.0 for example)
I don't know about the usefulness of this, but its worth looking into.
-and what about the fact that if provide allowed, between 2 packages more than one dependencies can happen (this is not programmed to pacman neither; at least what in the parts what I saw)?
Not sure what you are saying here. File conflicts are checked for...
-again, my main problem is the efficiency: now there are direct dependencies which can be checked very fast, and the provide-dependency which if you want to check, you must read the whole database to find providers.
Focus is correctness, not efficiency. Pacman prides itself because it gets dependencies right.
Yes, I see, that provide is needed, because you have to be able to define a "set of packages" somehow. What I say, that these sets of packages should be store explicitly (not only implicitly). There is not much difference between groups and providers from this point of view.
group = set of related packages, usually installed together provide = 'virtual' oackage, not all installed together but providing the same purpose -Dan
On 18:31 Tue 27 Feb , Dan McGee wrote:
On 2/27/07, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> wrote: [...]
-anyway, there is only one type of provide-dependencies (however, a "virtual" version number may not be useless: webserver 2.0 for example)
I don't know about the usefulness of this, but its worth looking into.
A couple of days ago I was talking with DaNiMoTh about this: foo-1.1 was in current, and he was writing a PKGBUILD for a software that needs foo >= 2.0 , but he also maintains a PKGBUILD for foo-svn, in this case, a provides=('foo-2.0') would be useful, so IMHO makes sense to implement it. Just my 2 eurocents. -- Alessio 'mOLOk' Bolognino Arch Linux Trusted User http://www.archlinux.org
in this case, a provides=('foo-2.0') would be useful Yes, in pacman-g2 this is implemented yet (they use this for
Hi! provide kernel 2.6.20-1), so we just "steal" the patch. Nagy Gabor PS: I'm dissappointed because of pacman and pacman-g2, I hope that the 2 developer group will help to each other (and they will develop pacman4 together) instead of silly flames...
On 2/28/07, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> wrote:
in this case, a provides=('foo-2.0') would be useful Yes, in pacman-g2 this is implemented yet (they use this for
Hi! provide kernel 2.6.20-1), so we just "steal" the patch.
providing the kernel is a bad idea. It is an Arch creedo that nothing depends=() on the kernel at all, so this provide=() is useless.
On Wed, 28 Feb 2007 13:50:38 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
On 2/28/07, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> wrote:
in this case, a provides=('foo-2.0') would be useful Yes, in pacman-g2 this is implemented yet (they use this for
Hi! provide kernel 2.6.20-1), so we just "steal" the patch.
providing the kernel is a bad idea. It is an Arch creedo that nothing depends=() on the kernel at all, so this provide=() is useless.
While this may be, I think that the idea is good: being able to apply a version to a provisio. Jason
On 2/28/07, Jason Chu <jason@archlinux.org> wrote:
While this may be, I think that the idea is good: being able to apply a version to a provisio.
a) I hate the term 'provisio', it's not even a real word 8) b) you mean that you want a provision to use the vercmp functionality in the case of a depends=() entry with a version? Can you give me a case where this would be useful (one that doesn't work simply using the version of the actual package)
On Wed, 28 Feb 2007 14:18:28 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
On 2/28/07, Jason Chu <jason@archlinux.org> wrote:
While this may be, I think that the idea is good: being able to apply a version to a provisio.
a) I hate the term 'provisio', it's not even a real word 8)
b) you mean that you want a provision to use the vercmp functionality in the case of a depends=() entry with a version? Can you give me a case where this would be useful (one that doesn't work simply using the version of the actual package)
a) Fair enough. I only used it because Judd used it. b) The first one that comes to mind would be a python/jython/ironpython/pypy example. Python programs can be written against python 2.5, but jython only supports python 2.2 (so it would provide=('python-2.2')). Pypy 0.99.0 provides python-2.5 (I believe). Same sort of thing for java with kaffe, jre, gcj, etc. If you think of a group of provisions, any time a fundamental change happens to the entire group, you'd probably want a new version number. Jason
On 2/28/07, Jason Chu <jason@archlinux.org> wrote:
On Wed, 28 Feb 2007 14:18:28 -0600 b) The first one that comes to mind would be a python/jython/ironpython/pypy example. Python programs can be written against python 2.5, but jython only supports python 2.2 (so it would provide=('python-2.2')). Pypy 0.99.0 provides python-2.5 (I believe).
Same sort of thing for java with kaffe, jre, gcj, etc.
If you think of a group of provisions, any time a fundamental change happens to the entire group, you'd probably want a new version number.
Added an FR: http://bugs.archlinux.org/task/6508
On Wed, 28 Feb 2007 13:50:38 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
providing the kernel is a bad idea. It is an Arch creedo that nothing depends=() on the kernel at all, so this provide=() is useless.
Buh? Kernel modules depend on their respective kernels. -- Travis
On 2/28/07, Travis Willard <travisw@wmpub.ca> wrote:
On Wed, 28 Feb 2007 13:50:38 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
providing the kernel is a bad idea. It is an Arch creedo that nothing depends=() on the kernel at all, so this provide=() is useless.
Buh? Kernel modules depend on their respective kernels.
Ack. Looking at CVS it appears this is true. Perhaps things are different now, w.r.t. having multiple kernels in the repos.... we should discuss this on the dev ML. Originally, none of the modules were supposed to depend on the kernel to allow people to rebuild their own kernels and reuse the modules PKGBUILDs via ABS.
participants (7)
-
Aaron Griffin
-
Alessio 'mOLOk' Bolognino
-
Dan McGee
-
Dan McGee
-
Jason Chu
-
Nagy Gabor
-
Travis Willard