Thursday 27 of September 2007 18:56:37 Xavier napisał(a):

Why?

Well if I understand correctly, supposing I have kdemod-kdebase installed, and some package requires kdebase, it will ignore the fact kdemod-kdebase is there and 'provides='kdebase'' and try and install kdebase from whatever other repo. Unless I'm reading you wrong ;-) In your case that you mentioned in your previous e-mail (which btw seems like a very chaotic explanation, maybe you can elaborate?) all that's needed to satisfy pacman and not have it pull in fglrx-libs, is to put 'provides=libgl' into libgl-dri. That would sort it proper. -- Mateusz Jędrasik <m.jedrasik@gmail.com> tel. +48(51)69-444-90 http://www.neowifi.pl

Mateusz Jedrasik wrote:

Thursday 27 of September 2007 19:02:48 napisałeś(-łaś):

...

your previous e-mail

Ofcourse, I meant Alexander's e-mail.

A provides - as far as I understand - is equal in priority to a pkgname in the local-db of pacman. Thus, your concern about provides loosing its meaning is not based on the reality it seems. Let me explain how I build packages: For each and every package that I build, I have a script that installs a base system and drops me into it. What it does is basicly a: $ pacman -S base -r /home/arch/buildroot.$?? Then installs a few additional packages in base-devel like gcc, bindmounts kernel provides folders and chroots me in there. Now, I want to update xf86-video-ati. When I do $ makepkg -csr it'll prefer fglrx-utils as libgl cos libgl is only a provides that is paid an average priority and thus, fglrx-utils is alphabeticly before libgl-dri... I renamed libgl-dri to just libgl. fglrx-utils and nvidia-utils still provide libgl but now must be explicitly installed. Then it's all back to the way it used to work. Pacman will just ignore the real libgl package on upgrades. So I ask myself where the problem is? :) Cheers, -F

On Fri, Oct 19, 2007 at 03:43:47PM -0500, Aaron Griffin wrote:

On 10/19/07, Alexander Baldeck <kth5@archlinuxppc.org> wrote:

...

I renamed libgl-dri to just libgl. fglrx-utils and nvidia-utils still provide libgl but now must be explicitly installed. Then it's all back to the way it used to work. Pacman will just ignore the real libgl package on upgrades.

Erm. I don't know if this is a real question or rhetorical, but I just want to point out that package names are searched for an exact match first, THEN provides, so a package will always be installed BEFORE a provides entry.

That's exactly why libgl-dri was renamed to libgl. For a saner default. Also, I don't see anything close to a question there, I think what Alex said was clear :) The libgl package will be ignored on upgrades AFTER fglrx-utils or nvidia-utils have been explictly installed.

On 9/27/07, Mateusz Jedrasik <m.jedrasik@gmail.com> wrote:

Well if I understand correctly, supposing I have kdemod-kdebase installed, and some package requires kdebase, it will ignore the fact kdemod-kdebase is there and 'provides='kdebase'' and try and install kdebase from whatever other repo.

This is a good point, BUT, these are two different issues. You are talking about already satisfied dependencies, when the original issue is about pacman auto-resolving dependencies. For instance, if you have something which is-or-provides kdebase, fine, the dependency is satisfied. However, if it is NOT installed, pacman needs to decide what to do, and will install kdebase (the real package name) before it installes kdemod-kdebase.

On Thu, Sep 27, 2007 at 07:02:48PM +0200, Mateusz Jedrasik wrote:

Thursday 27 of September 2007 18:56:37 Xavier napisał(a):

...

Why?

Well if I understand correctly, supposing I have kdemod-kdebase installed, and some package requires kdebase, it will ignore the fact kdemod-kdebase is there and 'provides='kdebase'' and try and install kdebase from whatever other repo.

Unless I'm reading you wrong ;-)

In your case that you mentioned in your previous e-mail (which btw seems like a very chaotic explanation, maybe you can elaborate?) all that's needed to satisfy pacman and not have it pull in fglrx-libs, is to put 'provides=libgl' into libgl-dri.

That would sort it proper.

It seems you are misunderstanding the issue. libgl-dri already provides libgl. But how do you choose between the multiple libgl providers? When you try to install a package requiring libgl, and you don't have libgl installed, nor a package providing it, pacman does the following : - look if a package named libgl is in a repo - if not, it looks for a provider, looking at each repos one by one (in the order defined in pacman.conf), at each packages in a repo one by one (probably in alphabetical order). What this means is that in any case (whether you are a nvidia, intel, whatever, user), pacman will pull fglrx-utils for satisfying the libgl dependency, only because it's the first one it finds. Currently, the user has to first install the correct libgl provider for his hardware (either libgl-dri or fglrx-utils or nvidia-utils), before installing any packages depending on libgl. Otherwise, if the user let pacman install fglrx-utils on his nvidia hardware, bad things might happen. Now, if libgl-dri is renamed to libgl, pacman will choose this package first, which should result in a saner default for everyone.