PR#1300: Revert "Recommend avoiding macros in file depenencies" - packaging-committee

packaging-committee

#1300 Revert "Recommend avoiding macros in file depenencies"

Opened 8 months ago by vondruch. Modified 8 months ago

vondruch/packaging-committee revert-macro-in-file-dependencies into master

Revert "Recommend avoiding macros in file depenencies"

Vít Ondruch • 8 months ago

c232fb5

guidelines/modules/ROOT/pages/RPMMacros.adoc

file modified

+1 -1

		`@@ -31,7 +31,7 @@`
		`Hello, World!`
		`....`

		`- [#macros_installation]`
		`+`
		`== Macros for paths set and used by build systems`

		`The macros for build system invocations`

guidelines/modules/ROOT/pages/index.adoc

file modified

-7

		`@@ -855,13 +855,6 @@`
		`not on any other functionality of any other package`
		`that might provide that directory.`

		`- When declaring file and directory dependencies,`
		- xref:RPMMacros.adoc#macros_installation[installation path macros] like `+%{_bindir}+`
		`- MUST NOT be used.`
		- `+%{_bindir}+` of the package that provides `+sometool+`
		- may be different from `+%{_bindir}+` of a package that requires `+sometool+`.
		- In such case, `+BuildRequires: %{_bindir}/sometool+` does not work as expected.
		`-`
		`=== Explicit Requires`

		`Explicit Requires are Requires added manually by the packager in the spec file.`

vondruch commented 8 months ago

This reverts commit 35d89f0.

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:

BuildRequires: %{?_root_bindir}%{!?_root_bindir:%{_bindir}}/checksec

if we expandeded the macros, it would look like:

BuildRequires: /usr/bin/checksec

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/ruby and some ruby package having:

BuildRequires: /usr/bin/ruby

How you conditionalize this to support either the system Ruby or the SCL Ruby? Is this the right version?

BuildRequires: %{?_root_bindir}%{!?_root_bindir:/usr/bin}/ruby

or maybe

BuildRequires: %{?_root_bindir:/opt/rh/rh-ruby30/root/usr/bin}%{!?_root_bindir:/usr/bin}/ruby

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.

decathorpe commented 8 months ago

Are there any official Fedora SCLs?

If there are not (I don't think so?, but please correct me if I'm wrong), Packaging Guidelines don't apply to third-party packages anyway, so they can do as they please. And I don't think official Fedora packages should bend over backwards for compatibility with third-party alternative Ruby packages.

vondruch commented 8 months ago

Are there any official Fedora SCLs?

If there are not (I don't think so?, but please correct me if I'm wrong), Packaging Guidelines don't apply to third-party packages anyway, so they can do as they please. And I don't think official Fedora packages should bend over backwards for compatibility with third-party alternative Ruby packages.

I see you have strong feeling about this, but I am talking about forward compatibility. SCLs are just an example. And apparently Flatpak does not have big enough community to face the issues yet. But maybe it will come to the point on day.

I am pretty sure there will come other technologies using similar method and expanding this macro will make their life just harder.

vondruch commented 8 months ago

And FTR, there is also request to implement something such as %{_system_bindir} in RPM:

https://github.com/rpm-software-management/rpm/issues/721

Which links back to #847 (just FTR).

decathorpe commented 8 months ago

I don't have strong feelings about this in particular, but we're not in the habit of making guidelines that only apply to non-Fedora packages ...

vondruch commented 8 months ago

First of all, SCLs macros are approved for Fedora:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_software_collection_macros

Nevertheless, these changes to guidelines were introduced just on vague claims the there might be changes in prefix _prefix, without even mentioning for what reason.

AFAIK the reason is Flatpak (from RPMs). There is no other reason to change _prefix in Fedora to my knowledge.

And I say that Flatpak will sooner or later face this issues. It is just matter of time when there will be needed to include pick your favorite tool in different then system version.

Edited 8 months ago by vondruch