libpoppler-qt4-devel is an arch-independent provides, just do 'urpmi libpoppler-qt4-devel' on a x86_64 system, it works(tm).

I've had a rather vague idea about raising the question of standardising the virtual provides in the distro, there should be:
Provides: %{name}-devel
Provides: lib%{name}-devel

either both of them in all packages, or one of them in all packages, so that we don't have to check urpmq --provides all the time. (Maybe it's time I raised the issue on the -dev ML).

Closing as invalid, as there's an arch-independent provides already in poppler-qt4-devel.

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Well, no if you have the 32bit repositories activated, you'll get libpoppler-qt4-devel from i586, at least this was the case for me, that is the reason of this bugreport. Also rpmlint is complaining about this one, as by it's name it is no arch-indepentend provide. poppler-qt4-devel would be.

About the other part about standardising virtual provides - yes, it's really time for that.

Works OK here, urpmi picks the x86_64 automatically:

$ urpmq --list-media active 
Core Release
Nonfree Release
Core32bit
$ urpmi --test libpoppler-qt4-devel
getting lock on urpmi
examining synthesis file [/var/lib/urpmi/Core Release/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Nonfree Release/synthesis.hdlist.cz]
examining synthesis file [/var/lib/urpmi/Core32bit/synthesis.hdlist.cz]
getting exclusive lock on rpm
found package(s): lib64poppler-qt4-devel-0.16.7-1.mga2.x86_64
preferring lib64cairo-devel over lib64cairo-xcb-devel
In order to satisfy the 'pkgconfig(cairo)[>= 1.10.0]' dependency, one of the following packages is needed:
 1- lib64cairo-devel-1.10.2-4.mga2.x86_64: Development files for Cairo library (to install)
 2- lib64cairo-xcb-devel-1.10.2-5.mga2.x86_64: Development files for Cairo library (to install)
What is your choice? (1-2)


please attach the output of urpmi --debug.

This is what I don't like about lib%{name}-devel:
 - for 32-bit systems, it's the name of the package *and* a provides
 - for biarch 64-bit systems, it's only a provides

this has the risk of a package manager choosing the real package over the virtual one.

BTW for software that uses pkgconfig we can use the pkgconfig(name) provides.

CC: (none) => cjw

(In reply to comment #4)
> This is what I don't like about lib%{name}-devel:
>  - for 32-bit systems, it's the name of the package *and* a provides
>  - for biarch 64-bit systems, it's only a provides
> 
> this has the risk of a package manager choosing the real package over the
> virtual one.
> 
> BTW for software that uses pkgconfig we can use the pkgconfig(name) provides.

pkgconfig provides indeed looks like an optimal solution, they're added automatically and should work(tm).

Also we wouldn't have to worry about breaking already working specs, since those pkgconfig provides have been there for ages, IIRC.

pkgconfig provides have the same drawback as devel(lib%name) provides, you can't install them directly, an urpmi devel(libfoobar) will fail, you need to escape the devel() with backticks. urpmi will error out on the opening bracket.

What is also important would be that every package gets a %name-devel provides, because those pkgconfig provides are automatically generated and may be prone to change or errors of that automatism, no?

Everything is prone to change/breakage, nothing works without problems %100 all the time.

The point is, we usually don't need to install the BR one by one, just urpmi the .spec file and it'll install all the BR, brackets and all.

Yes, i know that, just wanted to mention that as a drawback. Also urpmi --buildrequires works fine with that. Other than that i've got nothing against this. Thanks for your efforts with the virtual provides.