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