On Dec 2, 2010, at 1:07 PM, Eric MSP Veith wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello folks,
>
> I've been struggeling with an absolutely strange effect for some weeks (thus
> stopping my commits for that time because I though I was dumb). If a spec
FYI: You're not dumb, just that the %patch implementation in rpmbuild
has been tortured beyond belief.
There are _TWO_ %patch implementations, the "gud old stuff"
implemented in C, as well as a macro (that can be changed
without recompiling RPM) that is overloaded onto "%patch".
This is very very confusing and subtle when overloading occurs.
> file contains a macro not known to RPM, the scriptlet's iob ends up being
> empty.
>
> Seen in a %prep like this:
>
> - ---%<---
> %prep
> %setup -Tc
> %{__touch} '%{tmpfile}'
> - --->%---
>
> %tmpfile is a macro I injected during unit testing RPM's Ruby bindings.
> %{__touch} was something I *thought* would be there but wasn't. Actually,
> that's no big deal, but I never thought that %__touch wasn't defined,
> because the sympotom is: %prep is empty then.
>
> The reason is that the while(...) loop in parsePrep checks for PART_NONE,
> and when isPart() encounters the unknown macro, it switches to
> PART_ARBITRARY, thus the %prep scriptlet is empty.
>
Hmmmm ... yes I can believe that (but its kinda f*cked up behavior).
> This even happens if the code after the unknown macro is still valid, e.g.
>
> - ---%<---
> %prep
> %{__touch} foo
> %setup -q
> - --->%---
>
I can also believe that arbitrary tag processing ends
up processing %{__touch} out of order wrto %setup.
(aside)
But the '{' forbidden character or the zero-length arbitrary tag
name SHOULD have triggered a failure even if %setup wasn't executed
as expected.
> Here the %setup macro will never be executed.
>
> Is that intended?
>
Not intended, but a _REAL_ fix for the *.spec parser likely cannot be achieved
either: there's too many conflicting features colliding
in %setup/%patch, and in %prep sections, and grammar-less *.spec handling.
E.g. there are _TWO_ different implementations to fetch
missing source/patch/icon build elements, one using an external
curl invocation, the other using internal rpmio.
Consensus is futile.
Note that the actual flaw in the parser is even harder to see:
Parser's should parse and be side-effect free.
Attempting downloads during a parse -- not whether its
external/internal -- is the real design flaw.
If you cruft-up a toy reproducer, I might be able to tweak
(yes tweak) an error message out of rpmbuild somehow.
But there's so many flaws in the existing *.spec parser
that you are almost certainly gonna be bit by something.
73 de Jeff
> Eric
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQIcBAEBAgAGBQJM9+BTAAoJEIXD2TZ1epVBoAkP/A3xUrcyR3mtFL9eL0EXegeX
> 41eccywMeJTVfKxytBaZxxZRRhKN1JE1pXch1ii4/NVSrOppHM2rviq7zP3timYg
> JPxRm6Lt5gAfbu4BNPiWOmFedjf1MJZkOoZXLVOM+ZWFIzSogtig7I+uiYDMwCAY
> /vUuWBc+eIj8Cs+ItwBKt6TWhdl1VFw0g20mSVbLWfRimnjW0b9Yx1FIsrNnnk/Y
> Tra9zqKKiECDmmk1LH9kvwAxmopJD1uVujBt16CKwrWyFOOmpb+ZJpJL9YEKod2v
> U3bLSeh3OxuLu1hDdg4adxW5efq7m7iOUjWDhQc8OAHxABCN8IUP0fFmftd24f0d
> CJssZW0Tt4L+uvMpco35lSRM9wsqfV1qSek9lcoyWslnWBQXPtHJbH9gQa7vZWZy
> 63aiHcL04j9cqtxpBX8IajTMaPRNatIahxFkE/MaeeTc6GKKAbAZ+FIWAsWm4QnB
> UfiE1tULEV0hA4opFi6Yo+wvjr5GiJfmKdJuu0OrbafmV8qm9QWmaqYqbTvuSuXL
> Hy8PSw2aGt53tAgc8Cc+e2gkS2PvvrR41jWDf6S/XQKofWLnDnkZI+LKUrAwWhaC
> eATF3v8QPcId/ehEuF8ORvX9cIQuq0fMvX3q7dRz3bEgflSGYIgvALTVbIzwU3qT
> jF8fu4dUyqnnP5ql4xCV
> =cN9Z
> -----END PGP SIGNATURE-----
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List [email protected]
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List [email protected]
