> > Unfortunately I've just seen another similar package wants to use the info
> > in the shipped macros to ExclusiveArch itself so that rules out using a
> > %prep method.
>
> This won't work at all. The ExclusiveArch goes to SRPM headers so by the time
> %prep is executed, it is already too l
> Unfortunately I've just seen another similar package wants to use the info in
> the shipped macros to ExclusiveArch itself so that rules out using a %prep
> method.
This won't work at all. The ExclusiveArch goes to SRPM headers so by the time
%prep is executed, it is already too late.
--
Yo
And of course then we'll hit
https://github.com/rpm-software-management/rpm/issues/551
because that will want to use the main workdir in `_builddir`, which should be
`%{buildsubdir}` except the way it is set is not ideal, and it is not set
before the end of `%prep'.
--
You are receiving this b
Thanks a lot Panu, it like it a lot better than the shell script option!
Unfortunately I've just seen another similar package wants to use the info in
the shipped macros to `ExclusiveArch` itself so that rules out using a `%prep`
method.
I may end up replacing all this by sed-ing things in macr
Actually rpm does perform further expansions at the time of build too for the
various section templates, BUT the script itself from the spec is not
re-expanded. PR #480 sort of does this, except that it escapes all percent
signs automatically which in turn prevents actual macros from being expan
@nim-nim , ah sorry I missed the link in initial description and somehow
thought the "linked bit" meant something entirely different.
The issue here is not that %{load:..} does not work from %prep. It does, but at
the time of *parse*, not build. And since the macros file in question is packed
i
But that only shows that @pmatilai's point was correct: If you need to do
something dynamically in the build scriptlets, you need to do it with the shell.
That bit of the spec does things via the shell. So, yes, it's clearly doable
in some form: with the shell.
I don't understand how what you
https://src.fedoraproject.org/rpms/fontpackages/blob/master/f/fontpackages.spec#_84
--
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/571#issuecomment-430606822_
> whoever wrote the linked bit of spec
Err, what exactly are you referring to?
--
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/571#issuecomment-430586098
Well this is clearly doable in some form since whoever wrote the linked bit of
spec @rh did it.
The limitation seems to be that the result are shell variables not rpm
variables but from a practical POW the result is the same: the spec can use
values defined in macros it ships itself, and the ma
This is essentially the same misunderstanding as ticket #556: macros are
essentially a *pre-processor* for the spec, they are never dynamically executed
during the build.
If you need to do something dynamically in the build scriptlets, you need to do
it with the shell.
--
You are receiving th
Closed #571.
--
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/571#event-1903458372___
Rpm-maint mailing list
Rpm-maint@lists.rpm
Right now `%{load: }` is unconditionnaly evaluated before `%prep` starts,
making it impossible to load a macro file present inside a source archive. That
adds quite a lot of complexity when you want to version-control a macro file in
an upstream macro project
`%{load: }` should be evaluated at
13 matches
Mail list logo
