I install acidrip which depends on mplayer, I most likely want mplayer to be pulled, not mplayer-svn. OK, I understand this, and you are right, but I think, there is no definition for package "priority", if you _define_ that provide is not as "strong" as the "canonical" package, I will follow that rule. (Anyway, I think only one mplayer version should be exist in repos)
Let me explain an other (theoretical) example: Suppose that there is two kernel package in the sync repos: "vanilla" and "beyond" (RIP). And there are module packages compiled for them, such as nvidia-vanilla and nvidia-beyond, both provides nvidia. User does "pacman -S nvidia-utils" (which depends on nvidia). User has the beyond kernel installed, but pacman decides that it will install nvidia-vanilla and thus the kernel vanilla... probably the user doesn't want this. We can minimize the number of installed dependencies in alpm_resolvedeps or minimize the needed disk space etc. etc. but that wouldn't worth our effort. A bit off, for package maintainers: Personally I like the way, that I described above, and sometimes this "binary gentooish" packaging way would be nice. I mean, sometimes there are some very interesting but mutual ./configure options; in these cases multiple binary packages can be very helpful (-alsa, -oss, -gtk1, -gtk2, ...) and user could choose. These packages can be "identical" through provide. Any idea for this? flags? (special) groups (beyond and vanilla in our example) which helps pacman in the decision? [pacman must choose from nvidia-vanilla and nvidia-beyond and if these packages "flagged" by the groups vanilla and beyond, pacman can do a "-Qg vanilla" and "-Qg beyond" and it will see, that the installed vanilla group is empty, so probably the user wants to install a beyond package] Bye, ngaba ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.