Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
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-software-management/rpm/issues/313#issuecomment-526523412___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
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-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
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/when enabled during build. Adding similar for bzip2 is not that much harder. -- 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-327081503___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
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 because the most
complex (i.e. overly complex imho) expansions are typically what need escaping
of any sort, and complex macros are the hardest to debug when they break. And
break they will if you change rpm macro escaping ...
%expand is actually a hack, much like %quote is a hack: rpm needed to be
released, and there was no time to sort out some (silly imho) blocker packaging
problem). I've long since forgotten whatever the issue was *shrug*
%P and %S are hysterical artifacts trying to eliminate macros-implemented-in-C:
I doubt they are of any use outside of this replacement for %patch:
```
#
# The patch macro writes 1 line of shell code to (optionally) uncompress
# a file and apply using patch(1).
#
%patch(b:p:P:REz:F:d:) %{shrink:\
%define __patch_number %{-P:%{-P*}}%{!-P:0} \
%define __patch_file%{P:%{__patch_number}} \
%define __patch_suffix %{-b:-b --suffix %{-b*}} %{-z:--suffix %{-z*}} \
%define __patch_fuzz%{?_default_patch_fuzz:%(test %{_default_patch_fuzz}
-ge 0 && echo "--fuzz=%{_default_patch_fuzz} ")} \
%define __patch_options %{_default_patch_flags} %{-p:-p%{-p*}} %{-F:-F%{-F*}}
%{-d:-d%{-d*}} %{-R} %{-E} %{__patch_suffix} \
echo "Patch #%{__patch_number} (%{basename:%{__patch_file}}):" && (
%{uncompress:%{__patch_file}} | %{__patch} %{__patch_fuzz}%{__patch_options} )
|| exit 1\
}
```
(aside)
The effort was abandoned because a pure macro replacement for %setup (with
multiple options) was too much hassle. Now that popt can handle multiple
options (with POPT_ARG_ARGV) it might be doable, but even there one has to
handle integer coercion, ... *shrug*
I'd suggest just ripping out %P and %S: they are useless in practice.
--
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-327080542___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
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* expanding the argument for the second time. -- 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-327077255___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
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 %dirname). Not doing the expansion is rather easy to do with the existing subroutines (from nearly 20yo memory of the implementation ;-). Still the issue is an obscure corner case and there are other lurking issues with escaping like escaped '/' characters in paths (which are more constrained than strings), and with non-uglix M$_DOS path alternatives like "C:\HELLO\\WORLD' (capitals deliberately used). -- 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-326723449___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
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 string argument is needed, just like any "primitive" system call. -- 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-326722443___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
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/rpm-software-management/rpm/issues/313#issuecomment-326668996___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
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 subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/313#issuecomment-326663747___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
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___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
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.com/rpm-software-management/rpm/issues/313#issuecomment-326407345___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm's doFoo function tends to expand twice (#313)
(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/%
$ rpm --define '%xxx /hello//world' --eval '%{uncompress:%xxx}'
/usr/bin/cat /hello/%/world
$ rpm --define '%xxx /hello//world' --eval '%{quote:%xxx}'
\037/hello/%/world\037
```
--
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-326322673___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
