#64 Discourage use of macros for system executables
Closed: Fixed None Opened 10 years ago by tibbs.

Note that I can't unclude two underscores in a row in trac so I've inserted random spaces. Sorry.

I'd like the guidelines discourage use of macro forms such as _ cp, _ _chmod, _ _sed, etc. since in general they serve no purpose except to make things harder to type and read. However, I think there are some specific examples ( _python, perhaps _ _perl) where these are useful (python in the "build for interpreter versions" case, perl I'm not sure) and so a general ban isn't useful.

I see two possibilities:

Explicitly list discouraged macros. I count 44 from /usr/lib/rpm/macros, though there might be a case for _ _cpp. I've no problem doing this but the list is pretty long.

Or, craft a simple guideline:

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.


Is there really a need for all perl and python packages to use macro forms for the perl and python executables? I know about the "build for multiple pythons in one package" thing, but what about packages that don't need that? I've heard the argument that someone might want to redefine _ _perl locally for doing package builds or for bootstrapping a major interpreter version upgrade, but I don't know if that actually works in practice.

How strong should this be? I think "MUST NOT" is probably too strong, but we can also weaken to "use of XXX is strongly discouraged" or just plain "discouraged".

Simple guideline approved (+1:6, 0:0, -1:0)

Written up; announcement text could simply be the guideline itself, or perhaps this slightly shortened version:

Macro forms of system executables (such as %{_ _rm}) should not be be except when there is a need to allow the location of those executables to be configurable.

Metadata Update from @tibbs:
- Issue assigned to spot

4 years ago

Login to comment on this ticket.