[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)

Jason Tibbitts notifications at github.com
Thu Sep 27 19:19:31 UTC 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180927/6d3cc5de/attachment-0001.html>


More information about the Rpm-maint mailing list