On Mon, Feb 28, 2011 at 03:25:31PM -0500, Chuck Anderson wrote:
On Mon, Feb 28, 2011 at 12:13:22PM -0800, Toshio Kuratomi wrote:
> If people have additional reasons that macroizing all directory paths make
> sense, please let us know (here or as a comment in the ticket). Then FPC
> can decide whether to relax this rule or update the rule with information
> about why we have it in place.
The point of the macros is to ensure consistent use of paths between
the configure, install, and packaging stages so that builds don't
break if there are changes in any part of the chain.
Added to the comments as a reason to keep macroizing paths a requirement.
%configure uses those macros. If spec files were allowed to not use
the macros, then changes to %configure would break the spec files. So
if you are going to remove the requirement for the macros in spec
files, then the behavior of %configure should not be reliant on the
macros either. In fact, all use of such macros should be removed (not
disallowed, but removed from use in the standard build macros).
Not so sure that the consistency argument is so strong that this is the
case. As long as the macros used by the configure script and the hardcoded
paths used by the spec file are the same, nothing is broken. If the macros
change, it's going to be because we want to change the paths that they point
to for all packages. So we'd have to update any packages that use hardcoded
directories regardless of whether the hardcoded directories are also used
with %configure or not.