Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »
© Red Hat, Inc. and others.
This reverts commit 35d89f0f3ff118359f1fef1c328570a944e0ddf8.
TL;DR: Expanding
%{_bindir}does not help with deciding, where some specific tool comes from. Paths must always be taken with care once namespacing comes into the play.We have great amount of experience with this due to SCL and suggestion to expand the macros is not conceptual. Let me give you example. This one comes from Ruby:
if we expandeded the macros, it would look like:
That looks perfect right? According to the guidelines you say.
But now imagine we have the rh-ruby30-ruby package providing
/opt/rh/rh-ruby30/root/usr/bin/rubyand some ruby package having:How you conditionalize this to support either the system Ruby or the SCL Ruby? Is this the right version?
or maybe
Can you spot the issue with the above? We cannot build the package for other SCL. Or you have to use different magic.
Or you might suggest that the SCL branches should contain their customization and we should not bother, but then we should not bother with Flatpacka as well.
Don't get me wrong, I see the argument that expanding the
%{_bindir}might be in short term helpful for Flatpack, but conceptually, this is really wrong suggestion. IMHO, it is more flexible to use%{_bindir}to not use it. It won't save us with modifying the .spec file for some specific use cases, such as SCL or flatpak. Flatpak is just much simpler use case, that is it.