Macros in Source fields (was: Re: Prelink success story :))

Panu Matilainen pmatilai at welho.com
Fri Feb 27 15:14:20 UTC 2004


On Fri, 27 Feb 2004, Mike A. Harris wrote:

> On Fri, 27 Feb 2004, Michael Schwendt wrote:
> 
> Ok, I've snipped the entire message just to focus on the one 
> issue at hand.
> 
> >> howver feel free to edit your own spec
> >> files and change the version number in 10 places every time a new
> >
> >Why 10 places? Two places is enough. "Version:" and "Source:",
> >everywhere else %{version} is fine.
> 
> One place is enough.  "Version:"
[snip]
> In this case, the suggestion turns a very very slight
> inconvenience to someone such who rarely will ever be looking at
> the particular spec file or verifying it's contents and their
> origins, etc., and trades that in for a larger inconvenience
> directly upon the package maintainer, having to update the
> version number in 2 places constantly every time he updates the
> RPM package.  IMHO, it isn't worth it for a package maintainer to
> inconvenience himself for such a small benefit to a very very
> small number of people out there.  Additionally, it is no more 
> difficult for the person who wants that URL, to cut and paste it 
> in fragments to put it together, than it is for the maintainer to 
> put the version number in 2 places.
> 
> What's more, is that it could be rather easily scripted to parse 
> the Source lines out of a spec file and reconstruct the full 
> URLs.  It might even be possible to do this by querying the 
> specfile with the --specfile commandline switch, although I don't 
> know what the appropriate syntax might be.

Seconded. Don't make the hardworking packager make extra work, fix the 
tools so the macro constructs can be parsed and downloaded by QA where 
appropriate. 

The "no macros in sources" is one of my favorite love-to-hate rules in
fedora.us, but one I actually do appreciate when doing QA. We need a spec 
parser, not more boring human work (and yes it IS easy to forget to update 
the source entry to match version).

	- Panu -





More information about the fedora-devel-list mailing list