Conan-Kudo approved this pull request.
--
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/pull/221#pullrequestreview-39478138___
You pretty much convinced me expand after split is by far the saner thing to do
with this example:
```
$ rpm --define "%foo() 1:%1 2:%2" --eval "%foo %nil bar"
1:bar 2:%2
```
At least in the %autosetup case, the empty argument is harmless, and I think
given the %nil example, it could be
You know, that level of hackery and trickery sounds more like an argument
AGAINST this than for it.
I'm sure there are all sorts of funky hacks that allowing spec to access itself
would enable. And my message is: find some better way of doing it.
--
You are receiving this because you are
(but you also have the problem that there will be an empty argument if
with_int_bdb is not defined. Hmm. So revert that "expand after split" commit?
Too bad rpm does not have some quoting mechanism.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Yes it'd be a good thing, just not what I'd like to deal with right now.
Patches would be most welcome :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes, I also ran into that problem. But it's compatible to before ;)
Anyway, making the split macro aware would IMHO be a good thing. It would also
make it more consistent in regard to what expandMacro itself does, i.e. call
matchchar to find the end of a %{ or %( macro.
--
You are receiving
Hmm, expanding after splitting causes different problems (surprise surprise)
because, for example this breaks:
```%autosetup -n %{name}-%{srcver} %{?with_int_bdb:-a 1} -p1```
In this case it can be worked around by just dropping the space between -a and
1, but in general the split would now
