$RPM_SOURCE_DIR (Was: Problems with core review)

[John Dennis]

On Wed, 2007-02-07 at 14:12 -0600, Jason L Tibbitts III wrote:
> >>>>> "JO" == Joe Orton <jorton at redhat.com> writes:
> 
> JO> Seriously guys, I've said it two times already: if you want me to
> JO> repaint my bikeshed, first convince the central packaging
> JO> committee on high that your particular choice of bikeshed colour
> JO> not mine must be mandated across the distro.
> 
> Frankly we expected that many Rad Hat folks would simply not want to
> change things, and I suppose my personal hope of not having to
> involve the packaging committee in making tons of trivial rules in
> order to force people to change things is dashed by this very thread.
> But let's examine this specific situation in detail:
> 
> The main restriction against using $RPM_SOURCE_DIR is that you can in
> no way ever write anything to it.  That is the primary issue, and is
> implicitly given in other guidelines.  The package in question does
> not write to $RPM_SOURCE_DIR if I understand correctly.
> 
> For the package in question, $RPM_SOURCE_DIR can rather trivially be
> replaced by SourceN: and %{SOURCEN} tags.  Is that correct?
> 
> Are there situations where $RPM_SOURCE_DIR cannot be easily replaced
> by the use of SourceN: and %{SOURCEN} tags?  I can think of situations
> like looping over source files (which frankly I've wished I could do
> in the past) which are at best a good bit more difficult, but perhaps
> someone has the necessary wizardly knowledge.  I'm talking about doing
> things like copying ten source files into the buildroot without
> actually listing out ten %{SOURCEN} bits.
> 
> The consistency argument for using SourceN: and %{SOURCEN} tags
> instead of $RPM_SOURCE_DIR is obvious.
> 
> Is there a technical argument for using SourceN: and %{SOURCEN} tags
> instead of $RPM_SOURCE_DIR?  I'm afraid I don't know it.

Here are reasons for using RPM_SOURCE_DIR over SOURCEn

1) install "${RPM_SOURCE_DIR}/foobar dst" is *much* more readable than
"install ${SOURCEN} dst", it means as a mere human being I do not have
to act as a macro preprocessor in order to read the spec file and know
what is being installed where. Readability is a huge win!

2) you can loop, I do it all the time

for f in file1 file2; do
    install ${RPM_SOURCE_DIR}/$f dst
done

3) SOURCEn is a mechanism for source RPM manifests, if you want to use
it elsewhere then by all means go for it, but don't lose sight of the
fact it's a manifest directive with the side effect of introducing a
symbol into the rpm namespace, use of that symbol is purely optional.

4) It's none of your business how I implement something as long as its
not broken. Forcing every spec file to replace $RPM_SOURCE_DIR with
$SOURCEn is consistency without merit. Ralph Waldo Emerson wrote
"foolish consistency is the hobgoblin of little minds" It's my choice as
to what constitutes a maintainable spec file based on value judgments
and experience.

+1 for Joe Orton

-1 for the Bureaucrats in People's Central Packaging Committee and their
police who seek to banish me to the gulag for crimes against spec files
by virtue of improper thinking ;-)

-- 
John Dennis <jdennis at redhat.com>

Learn. Network. Experience open source.
Red Hat Summit San Diego  |  May 9-11, 2007
Learn more: http://www.redhat.com/promo/summit/2007