On Dec 30, 2007, at 10:22 AM, Ralf S. Engelschall wrote:

> On Sun, Dec 30, 2007, Jeff Johnson wrote:
>
>> Dunno whether there is any benefit other than debugging ease.
>> If the crypto becomes selectable, the QA matrix becomes much
>> more complicated for little perceived (imho) gain.
>>
>> But adding a popt option is trivial.
>
> For debugging purposes feel free to add such an option (but make it a
> hidden one under --help), but in general I would say we shouldn't  
> allow
> people to change the implementation too easily. Perhaps better is to
> expand a configuration macro to select the implementation...
>

Yah, once you start permitting choice, you eventually have
to implement lots of configgery baggage, including macros
and per-function overrides, and bindings and ...

Related issue:

popt is so useful (imho) that its deficiencies become extremely  
annoying.

The deficiency related to adding, say, --userpmbc or --userpmnss, is  
that
the cheap & easy implementation is prevented by this field in
struct poptOption:

     int val;                    /*!< 0 means don't return, just  
update flag */

popt is so widely used that its extremely unlikely that s/int/long/
can be accomplished, everyone will be pissed at the incompatibility.

But that's not a reason why popt-2.x can't be made rpm internal all  
over again.

For the moment, I'll pretend that
	--crypto {beecrypt | nss}
is a better UI implementation.

todo++. Yes with POPT_ARGFLAG_DOC_HIDDEN so that lusers
can reasonably claim that I'm depriving them of choice.

73 de Jeff