On Wed, 2007-02-07 at 14:12 -0600, Jason L Tibbitts III wrote:
> >>>>> "JO" == Joe Orton <jorton@xxxxxxxxxx> 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@xxxxxxxxxx>
Learn. Network. Experience open source.
Red Hat Summit San Diego | May 9-11, 2007
Learn more: http://www.redhat.com/promo/summit/2007
--
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
