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