[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpm-devel
Subject:    RPM CLI options are order dependent
From:       Jeff Johnson <n3npq () mac ! com>
Date:       2008-12-17 14:54:08
Message-ID: E778BAB9-6CB8-4A25-9339-8A777CBC0217 () mac ! com
[Download RAW message or body]

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

And the "fix" (gud enuf for mezzanine, not generally) that was  
hammered into
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.

The problem with --showrc (and --querytags, and --eval, mebbe 1 or 2  
other options)
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.

But --target fixing will be much harder because of the macro  
initialization
side effect. Because macros are included in paths that contain macro  
definitions,
there is an intrinsic chicken <-> egg problem.

I've tried several approaches to remove order dependence from RPM CLI  
options.

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.

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
predefined order, determinism is what is needed.

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
issue, does it?

How much should I work at fixing the above problem?

(aside)
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
to solve the precedence ordering problem twice in two different ways, an
evolutionary process to software development that takes years to  
converge.

Other opinions?

73 de Jeff
	

["smime.p7s" (smime.p7s)]

0	*H
 010	+0	*H
 00 rk 0
	*H
0|10	UDE10U
TC TrustCenter GmbH1%0#UTC TrustCenter Class 1 L1 CA1(0&UTC TrustCenter \
Class 1 L1 CA VI0 081202135405Z
091203135405Z0B10	UUS10UJeff Johnson10	*H
	
n3npq@mac.com0"0
	*H
0
Ҭ14B~:*;˄rx%I"^~22Wń9i,#O))~SC	` \
˨ŕ1i!~I5S)R&Ϥ(tuIAЈTOb߁>fN*5Q<1Rn&,f`iR!S~WUzsB \
SNg>Ox>ɐ{FMк00+00Q+0Eh \
ttp://www.trustcenter.de/certservices/cacerts/tc_class1_L1_CA_VI.crt02+0&http \
://ocsp.VI.tcclass1.trustcenter.de0U#0NjkJɻdK&0U00JU \
C0A0?	*,0200+$http://www.trustcenter.de/guidelines0U0UDL荺e9=7N&d?0TUM0K0I \
G EChttp://crl.VI.tcclass1.trustcenter.de/crl/v2/tc_class1_L1_CA_VI.crl03U%,0*+++
 +70U0
n3npq@mac.com0
	*H
c3#5@+Nwc<~3mJ \
2݉}dsOM3/cCåt(:ӌmxH#F?&N^?6c"*-7lu`+x|W \
ʕnbgҮV4H008 bnrd0 	*H
010	UDE10UHamburg10UHamburg1:08U
1TC TrustCenter for Security in Data Networks GmbH1"0 UTC TrustCenter Class 1 \
CA1)0'	*H 	certificate@trustcenter.de0
080718113854Z
101231225959Z0|10	UDE10U
TC TrustCenter GmbH1%0#UTC TrustCenter Class 1 L1 CA1(0&UTC TrustCenter \
Class 1 L1 CA VI00 	*H
0?N~ݤ㰾(ݙuLαlK%8H
~uH@MNCm]9Xq
K1~_݄Vfk(ѢzaW00'
@00+00L+0@http://www.trustcenter.de/certservices/ \
cacerts/tc_class_1_ca.crt0/+0#http://ocsp.tcclass1.trustcenter.de0U00JU \
C0A0?	*,0200+$http://www.trustcenter.de/guidelines0U0UNjkJɻdK&0U00 \
 ؆;http://crl.tcclass1.trustcenter.de/crl/v2/tc_class_1_ca.crlldap://www.trustc \
enter.de/CN=TC%20TrustCenter%20Class%201%20CA,O=TC%20TrustCenter%20AG,ou=rootcerts,dc=trustcenter,dc=de?certificateRevocationList?base?0
 	*H
ng,<H[<KB*8ُ˰y}e-pT-):mnzq/eJ̄tZմw"D˴W\&8kT.WƎ|W[30(0 \
0 	*H
0y10U
Root CA10Uhttp://www.cacert.org1"0 UCA Cert Signing \
Authority1!0	*H 	support@cacert.org0
070806160927Z
090805160927Z0810UCAcert WoT User10	*H
	
n3npq@mac.com0"0
	*H
0
MǼ~arqC?j(Ѝ.=
ܐ[m47囵{Hǰmgk׼=FlFَ^ \
c9hٕ/,fOcY;ik"XFS	)֟W:Z#AqW:_rIqc&ZZAKBH
 oY_x(V!zd	AHDJAdG*QXVr:tpM00U00V	`HB
 IGTo get your own certificate for FREE head over to \
http://www.CAcert.org0@U%907++ +7

+7
	`HB02+&0$0"+0http://ocsp.cacert.org0U0
n3npq@mac.com0
	*H
BmC2G$+`?kdC
o߫'iƬ'9\q459xOS@B= \
49ێ0أZ-n!Hrλy)gPmcFkrzGr1d3)g"LZ\bkR&h@[%|%@ht'?Нc]y4J


m
!ϵ[4QB}bK_gD,	?
wG:U\XC\!}i)7%7ufmW]-x|̭QćHxNF%3z3rR>~c͛y2GL<n#K/
  (_Q7nfrCejT \
q$,76ICm@C@)H4{\ZX̢T@niQjcN'.i. +(a
=F(>O1B0>00|10	UDE10U
TC TrustCenter GmbH1%0#UTC TrustCenter Class 1 L1 CA1(0&UTC TrustCenter \
Class 1 L1 CA VIrk 0	+ 0	*H 	1	*H
0	*H
	1
081217145409Z0#	*H
	1i2qkqIJ0	+7100y10U
Root CA10Uhttp://www.cacert.org1"0 UCA Cert Signing \
Authority1!0	*H 	support@cacert.org0*H
	1 0y10U
Root CA10Uhttp://www.cacert.org1"0 UCA Cert Signing \
Authority1!0	*H 	support@cacert.org0
	*H
!嗙\ۂ;&Wr \
kLo]~%Yr7y*b6>QUx@)q+޵-mCa~v{ގhQKny{$zjh
 ճ9qM￧wM+O0c \
Y?5MԶʫ"/63?;eG[87z3p{]c;BZ+hRyRw+*'BpW[U
 uT*=Ԅl
{o|


______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

[prev in list] [next in list] [prev in thread] [next in thread]

Configure | About | News | Add a list | Sponsored by KoreLogic