(duplicating first comment to generate mail to rpm-maint)
Watch this:
```
$ rpm --define '%xxx /hello//world' --eval '%xxx'
/hello/%%/world
$ rpm --define '%xxx /hello//world' --eval '%{shrink:%xxx}'
/hello/%/world
$ rpm --define '%xxx /hello//world' --eval '%{dirname:%xxx}'
/hello/%
Um, yes, many of the doFoo() routines re-expand the substituted text.
How exactly do you expect recursive substitution to Just Work if that was not
happening?!?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github
I didn't say they all should not re-expand. Things like "%{expand:}" obviously
have to do it.
--
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/313#issuecomment-326529732__
Your comments would be easier to understand if you also included what your
expectation actually is/was.
Dumping a list of obscure expansions with no other clue, forces the reader to
guess whatever you might consider the flaw.
Just saying ...
--
You are receiving this because you are subscribe
I'd expect `rpm --define '%xxx /hello//world' --eval '%{dirname:%xxx}'` to
return `/hello/%%` instead of `/hello/%`. Sorry for being not clear enough.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rp
Ah, got it.
Lots depends on what you expect of %dirname as a "primitive".
If you consider %dirname as, say, strrrchr(str, '/') with appropriate checks on
return value, then there isn;t a needs for an expansion per se.
But if you consider %dirname as a dirname(3) argument, then a fully expanded
Arguably, removing the extra expansion for all of the above expansions
returning strings might be less surprising (after thought): they are all string
manipulations without side effects, and so the extra expansion isn't needed,
and passing along '%%' is likelier more useful (at least with %dirna
So... some of the doFoo() primitives clearly could do without the second
expansion at the end, but at least these seem to require it:
- expand (obviously)
- uncompress
- P and S
As for uncompress, what it really needs is expansion of the uncompressor
command (ie the '%__bzip -cd' part) *without*
The important points here that needs to be considered:
The re-expansion of a string without a '%' character is entirely
transparent.
(i.e. the examples presented here are highly artificial).
Basically: It Really Doesn't Matter.
Changing how rpm does escaping is going to be highly annoying b
FWIW, %uncompress (and all the insane overhead in RPM to associate
compressors/uncompressors with compressed files) is better dealt with by
writing a meta-compressor in C that handles one well known set of options and
Does The Right Thing.
FYI: ZSTD will handle gzip/zlib, lzma/xz, and lz4 if/wh
I guess fixing this is too late for 4.15.0?
--
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/313#issuecomment-526517883___
Rpm-m
Yeah, a behavior change this big would've needed to be in the alpha already,
because it's bound to break a bunch of creative macros here and there.
--
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-softw
Closed #313 via 47dbb3e070efe8ef5583f22d4903a89bcda90d3c.
--
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/313#event-3022555800_
13 matches
Mail list logo
