[pacman-dev] CVS update of pacman-lib/pactest (pmenv.py tests/upgrade056.py)

[Dan McGee]

On 2/27/07, Nagy Gabor <ngaba at 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