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