On Mon, Oct 1, 2018 at 7:26 PM Neal Gompa <ngompa13@gmail.com> wrote:
> Generally, I'd consider most changes that are needed things that make the packages more compliant with the packaging guidelines - we expect packages to honor %{_prefix}. But there is one assumption some of the changes make that Petr Pisar pointed out to me that everybody might not agree with:
>
>    %{_prefix} and related macros specify the install location of this package, they
> should not be used for paths to tools used as BuildRequires.
>
> So I wanted to run that idea past the packaging list for comment. In many cases, that assumption can be fixed inside installed RPM macros (meson, ninja, and qt5 macros have already been fixed.) But in a few cases a spec file does make that  assumption.
>

This is actually a problem for when things like systemd binaries are
being referenced (as many of those are in /usr/lib/systemd, often
referenced as %_prefix/lib/systemd). There are also other packages
that ship using %_prefix/lib for the libexecdir because it's hardwired
that way. This situation is more common. That said, I would expect
that these wouldn't come up much, if at all, in Fedora packages in
BRs.

But I don't know how we would deal with a situation where a core
component being referenced is in /usr/lib/foo while the package in
question is being rebuilt as a Flatpak with its /app prefix?

I think you are saying that my statement above " %{_prefix} and related macros specify the install location of this package, they should not be used for paths to tools used as BuildRequires." is only a negative statement - it doesn't say what you *should* use for paths to tools.

My experience is that - for graphical applications and the libraries and runtimes they use -  the number of times an absolute path to a dependency is needed in a spec file and not covered by a macro is small. In the ~120 packages I've tried building with prefix=/app, I've hit this twice:

* In the endless-sky package, scons is invoked as '%{_bindir}/scons
* In the SDL package, it copies %{_datadir}/automake-*/config.{sub,guess} into the project

And in fact, the first could be handled by simply counting on $PATH and running 'scons'. My recommnedation for the second is to use /usr/share/automake-*/config.{sub,guess}. We're not going to move the FHS directories around in Fedora in any forseeable future - we're not going to change /usr to /user. And rebuilding the entire set of Fedora packages with a different %_prefix is not particularly useful - it's more useful to build one or a small subset of packages with a different %_prefix. So the assumption should be that tool X was installed in the standard Fedora location. But that's an assumption that it's not necessary to make very often.

Owen