Core Packages in Violation of the Fedora Naming Guidelines

Stephen John Smoogen smooge at gmail.com
Wed Jul 12 15:31:46 UTC 2006


On 7/12/06, Michael Schwendt <bugs.michael at gmx.net> wrote:
> On Wed, 12 Jul 2006 00:27:39 -0500, Tom 'spot' Callaway wrote:
>
> > On Tue, 2006-07-11 at 22:25 -0400, Matthew Miller wrote:
> > > On Tue, Jul 11, 2006 at 09:24:57PM -0400, Jeremy Katz wrote:
> > > > > The "all caps" hardcoded dist tag is wrong. Instead, you should use
> > > > > %{?dist} to let the buildsystem (both plague and brew support this)
> > > > > determine what the distribution tag is. It will fill in %{dist}
> > > > > with .fc6, for example. The dist tag bits are documented here:
> > > > > http://fedoraproject.org/wiki/DistTag
> > > > > Hardcoding the value for the dist tag is no longer allowed, since the
> > > > > buildsystem can do it for you.
> > > > I thought that things allowed hardcoding as long as you used the "right"
> > > > value.  Granted, doing so is probably kind of silly, but forcing
> > > > syntactic sugar is also overkill
> > >
> > > Also, 'cause sometimes maybe your spec file _is_ specifically for that
> > > release for some reason, and it's too different for a bunch of %ifs to make
> > > sense?
> >
> > Even in those cases, %{dist} will always be correct.
>
> In the resulting binaries, yes, but not in the .spec file. As the package
> maintainer, you don't want to be confused by seeing %{?dist} and assuming
> it is a valid spec for multiple dists when in fact it is not. This avoids
> mistakes during mass-updates to your package branches.
>
> Using %{?dist} must not be mandatory. Hardcoding the value %{dist} would
> expand to is justified in some cases.
>

My own private rpms that are only good for a certain release have a

BuildRequires: %{dist} == fc4 # change to appropriate buildsystem name for FC4

This way I know that it will not build on something else, and I don't
have to rely on the intelligence of others to understand my stupidity.


-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator




More information about the Fedora-maintainers mailing list