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
