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

[Mike A. Harris]

On Fri, 27 Feb 2004, Michael Schwendt wrote:

>> Macros work fine for me in Source tags, with URLs and without.  
>> See the xchat spec file for an example.
>> 
>> pts/34 mharris at porkchop:~/rpmbuild/rpms/xchat$ grep Source xchat.spec
>> Source:    http://www.xchat.org/files/source/2.0/xchat-%{version}.tar.bz2
>
>You haven't payed attention to the detail:
>
>  $ wget http://www.xchat.org/files/source/2.0/xchat-%{version}.tar.bz2
>  ERROR 404: Not Found.

Why on earth would you wget on the commandline with an rpm macro 
embedded into the commandline?  That is user-error.  Do not cut 
and paste the URL from the spec file to the commandline.

First of all, if you have the src.rpm installed, you _have_ the 
source code already, and do not need to download it.  If you want 
to anyway for some reason, you have the URL where it is located 
and can hand edit it to be useable if desired, or can cut and 
paste the directory and go from there.

I believe you can also query the spec file using --specfile to 
get the Source and Patch lines, however I'd have to confirm that.

There are numerous places in a given spec file that you can't 
just cut and paste it into the commandline and use for some 
purpose.  The intent of the specfile is to build the software and 
package it, not to facilitate cut and pasting things.


>And upon building source and binary rpm, the
>http://www.xchat.org/files/source/2.0/ is stripped off, and only
>the expanded xchat-%version.tar.bz2 is included in the RPM
>header.

$ rpm -qp --qf '%{source}\n' /mnt/redhat/beehive/comps/dist/fc2/xchat/2.0.7-3/SRPMS/xchat-2.0.7-3.src.rpm
xchat-2.0.7.tar.bz2

>So, what works "fine" for you? That you can obfuscate URLs with
>macros?

Huh?  The macro is there, for the same reason people use macro's 
in the C programming language, and other programming languages, 
as well as scripting languages.  So that you can update a 
constant in one single location, and have that constant propagate 
throughout the file(s) that it is relevant to.  By updating the 
single field "Version" in the spec file, that causes the %version 
macro to be created with the value that was supplied in the 
Version tag, and that value gets replaced throughout the spec 
file, thus making a single change propagate through everywhere 
necessary without requiring the developer to manually update a 
single constant in 50 locations.


>Or do you cut'n'paste part of the URL to visit the download
>directory in a browser?

No I do not.  I go to the xchat homepage located at 
http://www.xchat.org, find out what the latest version of it is, 
download all versions since the current rpm release, then create 
unified diffs between each release, and review them.  Once I've 
chosen the new version to update to, I edit the spec file and 
modify the Version: field to match the release.  That one change 
makes the version propagate through the spec file via macro 
expansion.

The Source field(s) in the spec file exists for 2 main purposes:

1) To indicate to RPM, the source files it should include in the 
spec file. Some or all of these will either be expanded by the 
%setup macro later on, or will be referenced directly via 
%{SOURCEnn} tags somewhere in the spec file.  All text leading up 
to the final "/" character is stripped from the filenames prior 
to accessing the files at build time.

2) To store the URL (if any given) in the Source field of the RPM 
header, for people querying the src.rpm from the commandline 
with rpm.

3) To provide a hint to the package maintainer or others, of 
where the file was obtained from.  Anyone sensible can easily cut 
and paste the directory name, and ftp/http to that location to 
find out what the current source is.  If all you want is the 
source code tarball that is in the src.rpm, then you have it 
already in the SOURCES directory.


I'm not about to change the Source fields in any of my own spec
files to hard code the version and remove the existing macro
usage, which is correct, howver feel free to edit your own spec
files and change the version number in 10 places every time a new
version of the software you're maintaining comes out, and ensure
every location is updated, and track down the bugs/problems 
caused if you forget in some location.




-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat