$RPM_SOURCE_DIR (Was: Problems with core review)

[Jason L Tibbitts III]

>>>>> "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.

 - J<