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:"
However, to show I am open minded team player type of guy, I am
willing to accept this change and change all of my own packages
to meet this request if:
- All major users of RPM, including Red Hat, SuSE, Mandrake,
Conectiva, all major rpm repositories such as freshrpms.net,
fedora.us, etc. agree upon making it an official standard which
will go into the official rpm documentation.
- Red Hat decides to adopt this internally as a standard,
either defacto or official.
Unless it is declared an official standard however, I do not see
any net increase of benefit to me as a developer to do it the way
that you suggest, and I do see some real world disadvantages to
doing it the way you suggest.
By using macros in the spec file on source lines, the package
maintainer gets the following benefits:
- It makes it easy to update the version throughout the spec file
in one single location, and without having to remember there
are two locations, which is the entire point of using a macro.
- It removes an element of human error, in which you can update
one of the locations and forget to update the other, possibly
introducing a bug into the package where new code doesn't
actually get used because both are sitting in the current
directory.
Additionally, the spec file syntax supports a URL tag, which
generally should point to the project's official homepage. If
there is no homepage, the closest thing to that should be pointed
to, which sometimes is nothing more than an ftp or http directory
link or similar. By following the URL link, which is unlikely to
contain any macros, you can follow the links from there to
download the software. This works both from the commandline
using links/lynx, or mozilla or some other GUI browser.
Another point, is that the number of people who actually look in
the spec file is relatively small. The number of those who are
likely to cut and paste any of the Source: line URLs onto the
commandline for wget, is very likely much smaller than that.
Since the source code is already present there already, very few
people are going to want to actually go to the full URL directly
and redownload the identical file that they already have. There
may be a few such as yourself who have special purposes, however
my main point here, is that the number of people will be
extremely small, possibly one.
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.
Anyhow, in closing, count me in for updating my packages to do
what you want, once it is a widely accepted and documented
standard that is being widely adhered to by the rpm packaging
populace.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
