@dmnks converted this issue into discussion #2766.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/721#event-10965341585
You are receiving this because you are subscribed to this thread.
Message ID:
And yeah, the point of those macros is NOT to make it easier to type. They're
there for flexibility.
Those of us who lived through the rise of the multilib will remember fixing a
thousand specs wrt /usr/lib -> %{_libdir} to accommodate for that. And /usr/doc
-> /usr/share/doc change before
It actually cites the source:
https://github.com/rpm-software-management/rpm/blob/6714ec7068a0343dcb4aaaeb4fe49940c129292f/macros.in#L960
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/721#issuecomment-1811979900
You are receiving
> The names are arbitrary
That said, I don't think they're completely arbitrary, the names have (most
likely) been copied from this GNU standard:
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
--
Reply to this email directly or view it on GitHub:
Actually, now that I *really* think about it, I must agree with that, too
:smile: It might have been one of the motivations originally (I have no facts
to back up that claim, though) but indeed, whenever I'm making dummy packages,
I just type out the paths by hand, precisely because of you what
> Save the packagers some typing
I generally agree with the rest of the discussion, but I want to reply to this
point in particular:
I very much disagree that those macros make things easier. Typing `/usr/bin` is
not any harder than typing `%{_bindir}`. The original form is shorter and also
> The thing is that I'll be fine if RPM does not provide any `_root` prefixed
> macros. But I'll be sad if Flatpak and RPMs will use different prefix for the
> same thing. You might leave this to SCL or Flatpak. OTOH, RPM is the common
> technology for both of them and the place where the
The thing is that I'll be fine if RPM does not provide any `_root` prefixed
macros. But I'll be sad if Flatpak and RPMs will use different prefix for the
same thing. You might leave this to SCL or Flatpak. OTOH, RPM is the common
technology for both of them and the place where the technologies
Yet another way to put it:
RPM providing a set of `%_root*` macros would basically mean: "In case you
choose to override the default %_prefix, these paths will be based on the
original value before the override". By that logic, why stop at the path
macros? Shouldn't RPM provide the
> The distributions can choose to override that default as they see fit.
If this happens, then yes, the (hypothetical) distribution may also want to
provide such a set of `_root` macros so that the packages can refer to those.
Overriding the default `%_prefix` when *building* a package (as is
In yet another words, AIUI, the two reasons we have the path macros are:
1) Save the packagers some typing
2) Allow for overriding the installation prefix (SCL, Flatpak, ...)
The only advantage of having such `_root` macros would be, in my opinion, the
former of the above. Which itself doesn't
> I don't care that much what the prefix is, but this kind of macros was
> essential for SCLs, which allowed to have one source package, but the build
> configuration changed the destination. In this scenario, there really needs
> to be distinction between files from system or from some
> Adding a collection of `_root` macros then just seems like a "remedy" for bad
> packaging.
I don't care that much what the prefix is, but this kind of macros was
essential for SCLs, which allowed to have one source package, but the build
configuration changed the destination. In this
I'm leaning more towards what @keszybz suggests above, which is that we need to
clarify the semantics of these path-based macros in the first place. Fedora in
particular prefaces the relevant
[section](https://docs.fedoraproject.org/en-US/packaging-guidelines/RPMMacros/#macros_installation)
An alternative approach: let's accept the fact that %_bindir=/usr/bin is here
to stay. Using a macro for "system binaries directory" is a legacy of old times
and we can just as well use the fixed path of "/usr/bin" for that everywhere.
(Using a macro for "where should I install my binaries",
I do prefer "root" over "system" as it's both more precise and generic.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
agree, `%_root_*` sounds good.
@ffesti @pmatilai would you like to add some comment here?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Just FTR, there is already precedent in software collections, where `_root_`
prefix [[1]] is used for the same purpose. It would be nice to reuse this
prefix instead of coming with new one.
[1]:
> The actual %meson change @ignatenkobrain landed substitutes Meson's bindir
> into the macro file
> (https://src.fedoraproject.org/rpms/meson/c/795680bbd10068673580261e134e2f4fbac4072d?branch=master)
> - which IMO is better tham %_system_bindir.
Yes, and I'm not happy about this because every
I'm not opposed to this proposal, but it does seem perhaps like
overcomplicating things.
Do we have examples where the %_system* macros would differ from the expected
FHS values and it would matter? %_libdir is probably the most variable thing
across different systems, but BuildRequires:
This just reveals how redefining of %_bindir (or I guess more correctly they're
redefining %_prefix) is not an ideal solution to the problem they're facing. I
honestly have no problem with specifying a full path in a build dependency in
the case that you can't for some reason specify a package
this would also help with cases where people define their own macro, for
example `%meson` used to be a `%{_bindir}/meson`, but I had to change it to
hardcode /usr/bin because once you redefine %_bindir, it just breaks...
--
You are receiving this because you are subscribed to this thread.
When people build with RPMs as part of flatpaks, they are changing %_bindir to
/app/whatsoever which is entirely valid case. But that means, you can't rely on
`BuildRequires: %{_bindir}/foo`. Specifying /usr/bin/foo in BRs is ugly as well
(because what if base system is actually installed in
23 matches
Mail list logo
