Remove requirement to use macros for paths

[Toshio Kuratomi]

Recently the question of why we require people to macroize their paths in
spec files (and by extension, patch build scripts to use the expansion of
our macros instead of hardcoded values) came up.  FPC only knew of one, not
so great reason: if the paths were to change, for instance a change in the
FHS, then spec files that use macros (in both the spec file and the
expansion of those macros is used in the upstream build scripts) would only
need a rebuild to pick up th new paths.

I then opened this ticket:  https://fedorahosted.org/fpc/ticket/67
for FPC to consider dropping using the directories as a requirement.

As recorded in the comments, some people have stepped forward with the
additional rationale that third-parties rebuilding our packages may wish to
install their rebuilds into a separate directory structure for their own
tracking purposes.  Having directory paths in macros allow them to do that
by redefining %{_prefix}, %{_sharedstatedir}, and a handful of other
toplevel directory macros.  If we allowed hardcoding of directories, then
they'd have to edit the spec file to achieve the same goal.

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.

Thanks,
-Toshio

[Bruno Wolff III]

On Mon, Feb 28, 2011 at 12:13:22 -0800,
  Toshio Kuratomi <a.badger(a)gmail.com&gt; 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. 
It matters for multilib stuff as the directory path is different on different
arches.

[Chuck Anderson]

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.

%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).

[Jon Stanley]

On Mon, Feb 28, 2011 at 3:19 PM, Bruno Wolff III <bruno(a)wolff.to&gt; wrote:

>  It matters for multilib stuff as the directory path is different on
> different
>  arches. 
%{_libdir} would still be a requirement for this reason.

[Toshio Kuratomi]

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.

-Toshio

[Michael Schwendt]

On Mon, 28 Feb 2011 15:25:31 -0500, Chuck wrote:

>  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. 
Especially what is used up to and including the %build section MUST match
what is used in the %install section. Else it would be possible to compile
into the software paths that don't match the installed file locations.

It's also one of the reasons why %makeinstall is not the preferred
%install method, as it bears the risk of inserting paths into the
installed files (possibly including the %buildroot prefix even) which
differ from what is used during %build.

>  %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). 
+1  Though, I wouldn't worry much about "breaking spec files", if that
also broke the build. 

Worse would be the cases where the spec file used hardcoded paths to
modify the source code (or to set up config/data files) with values that
differ from the macros used by e.g. %configure - without breaking the build.

[Christopher Aillon]

On 02/28/2011 12:55 PM, Toshio Kuratomi wrote:

>  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. 
True, but if we kept the macros, then we could simply do a mass rebuild 
instead of needing to edit %files.

[Toshio Kuratomi]

On Mon, Feb 28, 2011 at 03:34:10PM -0800, Christopher Aillon wrote:
>  On 02/28/2011 12:55 PM, Toshio Kuratomi wrote:
>  
>  >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.
>  
>  True, but if we kept the macros, then we could simply do a mass
>  rebuild instead of needing to edit %files.
>  
Agreed.  You snipped the part that I was replying to: if someone doesn't use
the macros for paths, then we should ban the use of the macros for
%configure.  I think that would be going a bit far.

-Toshio

[Ralf Corsepius]

On 02/28/2011 09:19 PM, Bruno Wolff III wrote:
>  On Mon, Feb 28, 2011 at 12:13:22 -0800,
>     Toshio Kuratomi<a.badger(a)gmail.com>  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.
>
>  It matters for multilib stuff as the directory path is different on different
>  arches. 
It matters for everything, because any of these directories may change 
at any time.

Those occasions are rare, nevertheless they happen.

Historic example: The "/usr/man -> /usr/share/man" mover.

Other unlikely to happen, but also not entirely impossible changes:
- Multi-arched "bindirs" (say /usr/bin -> /usr/bin64)
(This had been proposed and was discussed in the early fedora days)

- Multi-arched "libexec"
(Actually a special case of "multi-arched bindirs")

- Configuration path changes (aka. %_sysconfdir)
IIRC, %_sysconfdir had silently been changed several times, because it 
did not point to /etc in old RH rpms.

Ralf

[Nicolas Mailhot]

Le Lun 28 février 2011 21:13, Toshio Kuratomi a écrit :
>  Recently the question of why we require people to macroize their
> paths in
>  spec files (and by extension, patch build scripts to use the expansion of
>  our macros instead of hardcoded values) came up.  FPC only knew of one, not
>  so great reason: if the paths were to change, for instance a change in the
>  FHS, then spec files that use macros (in both the spec file and the
>  expansion of those macros is used in the upstream build scripts) would only
>  need a rebuild to pick up th new paths. 
Macroizing directory paths is very useful for SIGs to enforce consistency in
Fedora packages when a specific domain has no strong established file location
conventions and different upstream make radically different choices.

-- 
Nicolas Mailhot