When writing explicit BuildRequires and Requires in specs (particularly that could be used by other distros), is there a specific reason not to use (for example) pkgconfig(libcurl), where the package in question could be libcurl-devel or curl-devel or ambiguous-devel that provides it? Same for mono(nunit.core). Is there a use case in which it isn't beneficial, other than older RPM systems that don't do it internally?

Isaac Fischer
+1 (210) 775-2890
xwaver@gmail.com

Facebook LinkedIn Twitter Plaxo
IM: Google Talk/ xwaver@gmail.com AIM/ xwaver118 Skype/ xwaver118
Signature powered by WiseStamp 


On Fri, Feb 4, 2011 at 4:34 PM, Tom Callaway <tcallawa@redhat.com> wrote:
On 02/04/2011 02:24 PM, Mamoru Tasaka wrote:
> - Does this mean that mass packaging change will occur?
> - Currently rpmbuild detects pkgconfig .pc dependencies, so for -devel
>    packages containing pkgconfig .pc file now we usually don't have write
>    dependency for another -devel subpackage like "Requires: foo-devel"
>    explicitly (as rpmbuild automatically adds "Requires: pkgconfig(foo)")
>      (and I guess we shouldn't write such explicit requires when possible
>       and let rpmbuild handle such dependencies automatically)
>
>    If dependencies between (non-arch) -devel packages must be changed to
>    explicit arch-specific, it means that rpmbuild should also be changed
>    to add arch-specific pkgconfig Provides / Requires (e.g.
>    pkgconfig(x11)(x86-64) instead of current pkgconfig(x11)) ?
>
> - And as far as I am correct this also applies to other virtual Provdes/Requires
>    rpmbuild will automatically add.
>    - For example perl(BDB) devendency on perl-Coro.x86_64 will be satisfied by
>      perl-BDB.i686? Then this type of all virtual provides / requires rpmbuild
>      will handle must be changed??
>
>    Unless I am wrong to make things consistent such changes on rpmbuild must
>    be required. However is this actually we want?


The Guidelines currently only cover Explicit Requires and Provides, the
examples you point out are all implicit (Virtual). That isn't to say
that perhaps these items should also be arch specific, where applicable,
just that they are not yet addressed in the guidelines.

~tom

==
Fedora Project