$RPM_SOURCE_DIR (Was: Problems with core review)

[Michael Schwendt]

On 07 Feb 2007 14:12:24 -0600, Jason L Tibbitts III wrote:

> The consistency argument for using SourceN: and %{SOURCEN} tags
> instead of $RPM_SOURCE_DIR is obvious.

When _not_ using clean build environments, you can build an rpm with old
source files in $RPM_SOURCE_DIR, which are not packaged in %SOURCE tags.

So far so good. That used be one of the primary reasons why using %SOURCE
tags is preferred. Recommended. Encouraged.

However, when using mock or mach builds, this has become less important,
although it is still a pitfall when not using clean build envs.

What is left? How can you map between %SOURCE tags and files accessed
directly in $RPM_SOURCE_DIR? Is rpmlint capable of checking whether all
%SOURCE files are used? Even when accessed directly via $RPM_SOURCE_DIR?

> Is there a technical argument for using SourceN: and %{SOURCEN} tags
> instead of $RPM_SOURCE_DIR?  I'm afraid I don't know it.

What are the arguments for using %{SOURCEN} and only %{SOURCEN}?
What are all arguments against $RPM_SOURCE_DIR? Present the full
show before any of this becomes part of packaging policies.

I think John Dennis has given at least one good reason that justifies
why working directly within $RPM_SOURCE_DIR can be beneficial [point 1)].
As long as N is small, you can map easily between the macro and its
expanded value. Still, a spec file which works on %{SOURCEN} macros
is not as readable as one that uses full file names in $RPM_SOURCE_DIR.
Point 2) is moot, since you can loop over %{SOURCEN} macros in the
same way and even run  basename %{SOURCEN}  where useful. And btw,
one could also do "cp %{SOURCE1} %{SOURCE2} ." and then work on the
files from within $RPM_BUILD_DIR just as is done with many other
extracted tarball files.