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.
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
