RPM CLI options are order dependent

[Jeff Johnson]

I was reminded of this issue last night while sorting out
a problem with invoking
        rpmbuild -ba --target i386 foo.spec

RPM CLI options are order dependent.

The invocation I gace above works perfectly. What did *NOT* work
perfectly is this invocation
        rpmbuild -ba --define '_topdir /some/path' --target i386 foo.spec


place was to change the invocation to
        rpmbuild -ba --target i386 --define '_topdir /some/path' foo.spec

Yes, permuting --define and --target options changes rpmbuild behavior.

Another CLI option that is order dependent (and much more easily fixed
than --target) is this

This "works"
        rpm -v --showrc
while this does not
        rpm --showrc -v

None of the above is new behavior, the order dependence has been
in all versions of rpm since forever.

But perhaps its time (finally!) to attempt a better solution.


is that the processing (and exit) happens immediately, terminating
other option processing. Treating the handful of options that
do immediate processing-and-exit as an additional "other" mode
(like --install/--erase/--query/--verify/...) of operation is easy
pie fixing.


there is an intrinsic chicken <-> egg problem.



Here is what has already been tried and why it doesn't work:

1) Add a --predefine option that adds a macro definition but doesn't
trigger reading macro definitions.
        This "works" iff users are forced to specify --predefine before other
        options that need the definition.

2) Multi-pass option processing, and rewinding options.
        Way back when, RPM actually searched all options for --verbose/-v,
        set the verbosity, rewound the options, and set about processing
        with verbosity pre-initialized. Life was good.

        However, rewinding popt option processing is no longer simple. There
        are popt aliases and execs, and memory leaks not only from argv
        substitutions, but also from popt table entries that malloc memory
        while saving option args. And then there are other additional side
        effects because of added "features" while string encodings are
        converted on the fly.

        All solvable, but extremely fragile to maintain properly. Which
        is why rpm ceased to rewind its options years ago, it really isn't
        *THAT* ugly that -v must be specified before whatever depends on
        verbosity imho, ymmv.

3) (currently implemented) lazy macro initialization.
        There's only a handful of options that care whether macros are
        fully initialized (or not), the most important of which is
        --define. Macros are stacks, so all macro initialization must
        be completed before --define is pushed, or a later value from
        macro initialization will be pushed on top of the --define processing.

        The flaw with --define <-> --target is that each has side effects, and
        so are order dependent.


predefined order, determinism is what is needed.


issue, does it?

How much should I work at fixing the above problem?

(aside)

to solve the precedence ordering problem twice in two different ways, an


Other opinions?

73 de Jeff
        

And the "fix" (gud enuf for mezzanine, not generally) that was hammered into The problem with --showrc (and --querytags, and --eval, mebbe 1 or 2 other options) But --target fixing will be much harder because of the macro initialization side effect. Because macros are included in paths that contain macro definitions, I've tried several approaches to remove order dependence from RPM CLI options. There are many ways to solve the ordering problem, its no harder than identifying a precedence for each option, and then processing options in a deterministic And it certainly isn't the end of the world to just document that -- target must be used before any --define can be used, but that really doesn't solve any If left to my devisings, I'm likely to wire a precedence into some unused bits in the opt->argInfo field in popt option tables and use that precedence/grouping hint to sort the argv array handed to popt before/while option processing. Note that fixing precedence ordering in popt will only delay the rpm fixing because it introduces Yet Another Version pre-requisite building rpm itself. And so one gets evolutionary process to software development that takes years to converge.

smime.p7s
Description: S/MIME cryptographic signature