Re: [Guidelines Change] Changes to the Packaging Guidelines

[Isaac Fischer <xwaver@xxxxxxxxx>]

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@xxxxxxxxx

IM: xwaver@xxxxxxxxx xwaver118 xwaver118

Signature powered by WiseStampÂ

On Fri, Feb 4, 2011 at 4:34 PM, Tom Callaway <tcallawa@xxxxxxxxxx> 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

--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging

--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging