Extra % here

I have long been a proponent of avoiding path macros outside of situations like %_libdir where they are required or where they enhance readability, so I'm certainly happy with this but I suppose I'm a bit biased.

Extra % here

Thanks, fixed.

I wonder if there is another place of the documentation that might need to be updated.
When referring to macros for paths, the documentation says:

So, it’s usually preferable to not hard-code these paths in spec files either, but use the same macros for consistency.

Source: https://docs.fedoraproject.org/en-US/packaging-guidelines/RPMMacros/#macros_installation

If I'm understanding the issue correctly, the part that I quoted may need to be removed and the previous part might need to be modified to:

... use the values defined by RPM to set installation paths for packages and when referring to files and directories installed by the current spec file.

Is that interpretation correct?

Isn't https://pagure.io/packaging-committee/c/35d89f0f3ff118359f1fef1c328570a944e0ddf8 just referring to paths in BuildRequires/Requires ?

... use the values defined by RPM to set installation paths for packages and when referring to files and directories installed by the current spec file.

Is that interpretation correct?

Something like that, yes.

Isn't https://pagure.io/packaging-committee/c/35d89f0f3ff118359f1fef1c328570a944e0ddf8 just referring to paths in BuildRequires/Requires ?

By the same logic, if you can't rely on using e.g. Requires: %{_sbindir}/alternatives, you also can't call %{_sbindir}/alternatives in scriptlets etc. either. Besides, it doesn't make sense for the style of these two (the file dependency and its invocation in the body of a spec file) to be different.

So does this mean that something like this is wrong:

https://github.com/rpm-software-management/rpm/blob/master/macros.in#L769

So does this mean that something like this is wrong:

https://github.com/rpm-software-management/rpm/blob/master/macros.in#L769

Since we anyway have to override PKG_CONFIG_PATH (and other such variables) to search both /app and /usr prefixes simultaneously, the question is practically moot.

So does this mean that something like this is wrong:

https://github.com/rpm-software-management/rpm/blob/master/macros.in#L769

Since we anyway have to override PKG_CONFIG_PATH (and other such variables) to search both /app and /usr prefixes simultaneously, the question is practically moot.

I understand this specific case may not matter for flatpak builds, but I'm asking more in general is something like this not allowed according to the packaging guidelines.

I understand this specific case may not matter for flatpak builds, but I'm asking more in general is something like this not allowed according to the packaging guidelines.

The difference here is that any given individual dependency will only be in one location at a time, and the question is how to refer to that dependency in a way that applies to both regular and flatpak builds. When it comes to search paths though, an override is anyways necessary to handle multiple prefixes, and I'm not proposing that they should (since, in the case of regular builds, this would just result in duplicate entries). Therefore, I don't want to compare these use cases at all.

The commit message is too terse to my taste.

I think the change is correct and the reasons is well documented in the commit message.

Rebased; how can this be moved forward?

I have reviewed this as an user and it LGTM.
This documentation works before and after the bin/sbin merge.