| |
@@ -1069,7 +1069,20 @@
|
| |
* 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 `+%{__python3}+` is acceptable.
|
| |
+ Macros with names beginning with underscores
|
| |
+ are generally considered to be implementation details internal to RPM
|
| |
+ and its associated macro packages
|
| |
+ and SHOULD NOT be referenced in specfiles
|
| |
+ except to set their values in order to influence RPM behavior.
|
| |
+ This implies that macro forms of system executables SHOULD NOT be used.
|
| |
+ For example, `+rm+` should be used in preference to `+%{__rm}+`.
|
| |
+ However, in some cases needed data are simply not provided
|
| |
+ under names which are not prefixed with underscores.
|
| |
+ If that is the case, the macro named with leading underscores MAY be used.
|
| |
+ Authors of macro packages are encouraged
|
| |
+ to avoid using leading underscores
|
| |
+ when naming macros which are intended to be used in specfiles
|
| |
+ (as opposed to being set).
|
| |
|
| |
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.
|
| |
|
| |
decathorpe commented 3 years ago
This imples two or more underscores, right?
Maybe "2+" should be explicit. One underscore is fine (c.f. _bindir, _libdir, etc.), right?