From 126be044af3e97fd95d2f654586308c0fa701138 Mon Sep 17 00:00:00 2001 From: Jason Tibbitts Date: Jun 21 2019 14:39:05 +0000 Subject: Change old mention of %__python to %__python3 %__python was being used as an example of a valid macro for a system executable, but that kind of conflicts with our efforts to get rid of the unversioned python macro. This is a quick fix so that the section isn't totally wrong. --- diff --git a/guidelines/modules/ROOT/pages/index.adoc b/guidelines/modules/ROOT/pages/index.adoc index a5a1b49..bfa5326 100644 --- a/guidelines/modules/ROOT/pages/index.adoc +++ b/guidelines/modules/ROOT/pages/index.adoc @@ -963,7 +963,7 @@ Packagers are strongly encouraged to use macros instead of hard-coded directory * The package must be consistent. For any given path, within the same spec, use either a hard-coded path or a macro, not a combination of the two. * %\{_libdir} must always be used for binary libraries due to multi-lib, you may not substitute a hard-coded path. -Macro forms of system executables SHOULD NOT be used except when there is a need to allow the location of those executables to be configurable. For example, `+rm+` should be used in preference to `+%{__rm}+`, but `+%{__python}+` is acceptable. +Macro forms of system executables SHOULD NOT be used except when there is a need to allow the location of those executables to be configurable. For example, `+rm+` should be used in preference to `+%{__rm}+`, but `+%{__python3}+` is acceptable. Having macros in a Source: or Patch: line is a matter of style. Some people enjoy the ready readability of a source line without macros. Others prefer the ease of updating for new versions when macros are used. In all cases, remember to be consistent in your spec file and verify that the URLs you list are valid. spectool (from the rpmdevtools package) can aid you in checking that whether the URL contains macros or not.