Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
Closed #547 via #1392. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/547#event-3892043975___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
Pulled that part out of #1383 for now to avoid piling on.
In the meanwhile I've been pondering about that '..' syntax which is as
arbitrary as anything. Maybe a better syntax would be a wildcard '*' instead, ie
```
%foo(*) {
}
```
Thoughts?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/547#issuecomment-705447311___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
Implemented in PR #1383, but not specific to Lua despite the PR title. Simply pass '..' as the option string, eg `%foo(..)`. This will skip option processing in rpm, and any options that a macro might receive are simply passed as raw string arguments. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/547#issuecomment-704249870___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
One possibility might be giving this power only to Lua macros via the native argument mechanism (ie the proof-of-concept stuff in #1063) -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/547#issuecomment-601681837___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
> Since you asked, here's a small proposal and a possible alternative. > > Proposal: In a macro definition, using an argument string of `-` (as in > `%define macro(-)`) indicates > that getopt processing should not be done at all, and all supplied arguments > and options should be > delivered directly to the macro via `%*` (or `%**`, or even something else) > without interpretation by > RPM. `%#`, `%1` and such would not be valid in this case. Thank you Jason That's more or less what I had in mind, except I'd have used `%define macro(^)', and allowed mixing argument processors ie `%define macro(abcd:^)' → -a -b -c -d are handled the classic way, and every other flag including long, repeated, and non-flag arguments, is dumped to `%**` (ideally you have one variable for everything, and one variable for everything except flags rpm processed directly) The actual magic character in `%define`, and the actual rpm variable where unprocessed flags are dumped, does not matter, as long as it exists and is documented. But just disabling completely the classical argument processor works for me. Mixing is a convenience, any smarter argument processor can also do the basic processing rpm does today. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/547#issuecomment-425387659___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
@nim-nim, @jasontibbitts okay I see now, thanks for the explanations. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/547#issuecomment-425351184___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
First: use a macro file, not a %define, to hide abc...XYZ. If you must have
package specific macro overrides, the use %{load:...} and bury the override in
a SourceN: directive. The most important reason to use a macrofile is
readability: you can split a definition over multiple lines, unlike a %define,
because macro files permit escaped new lines.
Second: if you don't want getopt(3) processing, then simply do not use a
parameterized macro, and arrange for whatever helper you wish to execute to
appear at the end of whatever expansion is attempted.
Third: your suggestion of the definition is at least a reasonable proposal. atm
the string is exactly what getopt(3) expects, nothing more nor less.
Parameterized macros cannot handle long options because getopt(3) cannot handle
long options. And if the options/args are not parsed, then constructs like %*
or %** are just "I want a pony" wishes.
Fourth: parameterized macros are not functions, nor is macro expansion anything
more than recursive string substitution on mild steroids. If you have real
programming needs, then use a real programming language like shell, Python,
etc, instead of honking at length about rpm deficiencies.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/547#issuecomment-425251334___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
What we're trying to get around is having to do `%define foo(abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ)` so that the macro can just handle parsing `%**` itself, and then still not being able to handle anything that looks like a long option. That hack allows repeated arguments, which is the main annoying thing from my perspective. But it does not permit long arguments unless users just always stick '--' early in the argument list. That's an odd wart. (And then you get '--' in '%**' and so can't use that in your parsing.) What's really desired is to just not call getopt() at all. Since you asked, here's a small proposal and a possible alternative. Proposal: In a macro definition, using an argument string of `-` (as in `%define macro(-)`) indicates that getopt processing should not be done at all, and all supplied arguments and options should be delivered directly to the macro via `%*` (or `%**`, or even something else) without interpretation by RPM. `%#`, `%1` and such would not be valid in this case. Alternative proposal: Allow `-` in an RPM option string definition to allow `--anything` to appear in the argument list (if it's even possible for getopt to do that). Currently the error you get is simply `invalid option `-`` which makes it seem as if just allowing '-' as an option might be enough. We'd still have to include the entire alphabet in the declaration, though, but that's minor. Alternatively, if there's some other hack that would work, I'd be happy to hear it. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/547#issuecomment-425212096___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
That is indeed the case that some flags are handled by the macro processor, while others are passed along, when -- is used to stop getopt(3) option processing. Long options would need a means to be specified in the macro definition, and multiple duplicated options, and or arg types, would also need to be included or appropriately defaulted. Devise a syntax for what you are requesting if you wish this RFE implemented. Or supply some reasonable usage case instead of just complaining. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/547#issuecomment-425125507___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
But that exposes to the macro user that some flags are handled by the rpm argument parser and others by something else. And that forces the macro user to use a specific flag order. The macro user does not care about all this – that's a macro implementation detail -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/547#issuecomment-425109638___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
RPM already has support for %(...) shell diversions and %{lua:...} embedding,
both of which are well known programming paradigms that should be used instead
of macros wherever you find your efforts limited by lack of a failure message
from a macro option/argument.
--
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/547#issuecomment-423695173___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)
rpm macro argument parsing is ancient and limitating, it can not handle
full-word flags, it can not handle repeated flags, and so on
please add a syntax to specify a macro should not fail when used with a flag
not declared to rpm argument parsing, so all those new forms of arguments can
be collected in %{?*} and fed to something a bit smarter
--
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/547___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
