RPM uses macros instead of envvars to increase reproducibility of builds.
How rpm is configured, and how rpmbuild is invoked, are matters that you need
to take up with build systems. That would also be true if envvar's were used
instead of macros.
Note that there is (or at least was) a 3rd way
Alternatively, choose known file names, and use a %load for each file in a spec
file.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Then invoke rpmbuild with --macros, appending your patterns at the end of the
colon separated list.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I am looking for a way to tell RPM that there might be some paths which might
contain arbitrary macro files. If such files are located, they should be loaded
by RPM.
IOW given there is metapackage like this \[[1]\] and I have installed
rh-ruby22-runtime package and I call ```scl enable
What exactly are you looking for?
You have yet to post any example here that does not include a pattern when the
documentation for %load explicitly says "file".
Have you tried strace to verify that rpm is trying to load a file?
--
You are receiving this because you are subscribed to this
I am not surprised at all that the wildcard is not supported. I am just
surprised I am suggested to use ```%load``` where it is not usable in its
current form.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Try removing the leading '?', and note that the added documentation explicitly
says "file" not pattern.
You can verify the load (or attempt) by using "strace -e open"
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Of course, that was just test. So I did different one:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index c9ff8dc..ecc5e93 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -102,8 +102,7 @@ Source14: test_systemtap.rb
# The load directive is supported since RPM 4.12, i.e. F21+. The build process
```
+%{?load:%{_rpmmacrodir}/macros.*}
```
This is redundant... RPM already does this...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This passes:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index c9ff8dc..3748781 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -104,6 +104,7 @@ Source14: test_systemtap.rb
# fails on older Fedoras.
%{?load:%{SOURCE4}}
%{?load:%{SOURCE5}}
+%{?load:%{_rpmmacrodir}/macros.*}
# Fix
Just quick test:
~~~
$ git diff
diff --git a/ruby.spec b/ruby.spec
index c9ff8dc..fc2e68b 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -104,6 +104,7 @@ Source14: test_systemtap.rb
# fails on older Fedoras.
%{?load:%{SOURCE4}}
%{?load:%{SOURCE5}}
+%{load:%{_rpmmacrodir}/*}
# Fix ruby_version
Ok, so I can imagine I put this into every SCL meta package, but then I have a
few questions.
* Does the load macro support the wild cards?
* What happens if there is no such macro file? Does it fail or just continue?
--
You are receiving this because you are subscribed to this thread.
Reply
@voxik No, no no. You can put the macros wherever, just have a `%{load:..}`
directive that points to it.
If I remember correctly, you can also do something like
`%{load:/opt///rpm/macros.d/macros.*}` to load it.
However, you have to be careful, since if the macros don't exist, the spec will
I am disappointed. Many people calls SCL being big hack, but you won't make it
any easier :(
So if I read it correctly, the suggestion is that scl-utils should put
something into ```%{_rpmmacrodir}``` (please note that the collection itself
are generally not allowed to put anything outside
I guess this was always more a matter of missing documentation than missing
feature.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #363.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/363#event-1504309831___
Rpm-maint mailing list
Doh... Well it's there now:
https://github.com/rpm-software-management/rpm-web/commit/87e2b6ffa451593a4077570f26182c2bb3dbe440
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@khardix It's not in the website, but it's in the documentation generated by
rpm itself:
https://github.com/rpm-software-management/rpm/blob/master/doc/manual/macros#L91
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@n3npq @Conan-Kudo Thanks a lot for pointing that out – I kind-of feel like I
should RTFM more .
> Have you thought about using the %{load: in the spec to load extra macros?
@Conan-Kudo: This might again be just search issue, but could you point me to
the documentation of the `%{load:...}`
@n3npq Good to see that extending RPM to support env variable shouldn't be
hard, since RPM has the --macros CLI option alrady.
@Conan-Kudo It might be risky, but we are doing it anyway. This is request to
do it a bit better way then we are doing it now. It would even improve the
situation,
Um, this simply isn't true.
RPM has always searched multiple directories for macro definition files.
See also the --macros CLI option (which takes a colon separated set of paths to
load) to override the default value for macro search paths.
--
You are receiving this because you are subscribed
Currently, RPM looks for macro definitions in only one directory, which is
hard-coded and cannot be changed.
This pose significant complication for packaging of RPM Software Collections
which need to provide their own version of macro files – basically, the SCL
installs all its files into
22 matches
Mail list logo
