Note: %{_libdir}, because of multilb, would remain a requirement even if we removed the requirement on other paths.

From notting and jds2001: If a site wants to do an internal rebuild of a package they may want to install the files in a location other than /usr. If they do that, then redefining a few macros like %{_prefix} and %{_sharedstatedir} before doing an rpmbuild --rebuild is the quickest and easiest way to do that. If we allowed people to use hardcoded directories, the people rebuilding would need to edit at least the %files section of the spec file to achieve this.

To be honest, I have some trouble getting from "someone may want to do something bizarre and this happens to make it easy for them" to "we have to mandate it for every package in the distribution". There are lots of odd things people may want to do with our packages, but we shouldn't inflict those oddities on our packagers.

Re: From notting and jds2001

Even if that may work, don't forget that we already strongly discourage RPM's Relocatable Packages for reasons, such as hardcoded paths in the software (even if such details are not commented on in the guidelines). We don't require packagers to substitute every hardcoded path in the source code with our macros, if a configure script doesn't do that. Not even paths that start with /etc or /usr. It would be difficult to do that and would add unnecessary complexity (such as patching install scripts, so they would create the relocated now-missing system directories with proper ownership and permissions).

Using macros in the spec file ensures consistency between what's given to configure (usually via %configure) and what's used in the spec file.

If a site wants to do an internal rebuild of a package they may want to install the
files in a location other than /usr. If they do that, then redefining a few macros
like %{_prefix} and %{_sharedstatedir}

Paths are the least of their problems, if they want to do that. They almost certainly also need to:

1. Change the name of the package, and maybe conflict with the original.

2. Audit any provides it gives off, and what requires those things.

3. Make sure the package itself actually works, when it's in a non-std. location (shlib changes, path changes, etc. etc.) Some of these will be really annoying.

4. Watch "upstream" changes to the package.

Replying to [comment:5 mschwendt]:

Re: From notting and jds2001

Even if that may work, don't forget that we already strongly discourage RPM's Relocatable Packages for reasons,

You are talking about relocatibility at binary level (binary rpms), notting and jds2001 are talking about relocatibility at source level (rebuilding rpms) - These are separate and non-connected issues.

Replying to [comment:7 james]:

1. Change the name of the package, and maybe conflict with the original.

Why? The entire point is that the package is parallel installability (but as you'll see later, how I do it doesn't really matter what the package is called)

1. Audit any provides it gives off, and what requires those things.

Again, irrelevant for reasons you'll see later (for me, for others I can see where it would be very relevant)

1. Make sure the package itself actually works, when it's in a non-std. location (shlib changes, path changes, etc. etc.) Some of these will be really annoying.

Yep.

1. Watch "upstream" changes to the package.

Yep.

What we actually do is build the RPM in an internal koji instance. We then take the binary RPM, use rpm2cpio to get the contents, and put the binary on a shared filesystem of some type. I'll admit, this is something of a unique use case (but a very important one for us and I'm sure many other people).

So what does building in an RPM with koji get us, you ask? It ensures reproducible builds, the entire tenet that RPM was built upon. The fact that we're only using it at build time is largely irrelevant.

However, that fact makes it extremely relevant to pay attention to proposed changes like this one that apply to the build-time environment.

Proposal replacement for first sentence in Guidelines#Macros

"Packagers are strongly encouraged to use macros instead of hard-coded directory names (see Packaging:RPMMacros). However, in situations where the macro is longer than the path it represents, or situations where the packager feels it is cleaner to use the actual path, the packager is permitted to use the actual path instead of the macro. There are several caveats to this approach:
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"

Approved (+1:6, 0:0, -1:0)

Announcement text:

Some clarification was added to the Guidelines section on Macros. Previously, it said:

"Use macros instead of hard-coded directory names (see Packaging:RPMMacros )."

Now, that line has been replaced with:

"Packagers are strongly encouraged to use macros instead of hard-coded directory names (see Packaging:RPMMacros ). However, in situations where the macro is longer than the path it represents, or situations where the packager feels it is cleaner to use the actual path, the packager is permitted to use the actual path instead of the macro. There are several caveats to this approach:

• 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. "