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

Aaron Griffin aaronmgriffin at gmail.com
Tue Feb 27 18:17:39 EST 2007


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




More information about the pacman-dev mailing list