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
On Mon, Feb 28, 2011 at 12:13:22 -0800, Toshio Kuratomi a.badger@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.
On Mon, Feb 28, 2011 at 3:19 PM, Bruno Wolff III bruno@wolff.to wrote:
It matters for multilib stuff as the directory path is different on different arches.
%{_libdir} would still be a requirement for this reason.
On 02/28/2011 09:19 PM, Bruno Wolff III wrote:
On Mon, Feb 28, 2011 at 12:13:22 -0800, Toshio Kuratomia.badger@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
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).
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
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.
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
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.
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.
packaging@lists.fedoraproject.org
-
Bruno Wolff III -
Christopher Aillon -
Chuck Anderson -
Jon Stanley -
Michael Schwendt -
Nicolas Mailhot -
Ralf Corsepius -
Toshio Kuratomi