Re: [rh-rpm] Re: Doubts about nested %if in spec file

[R P Herrold <herrold owlriver com>]

On 30 May 2002, Edward C. Bailey wrote:

> would be scripts to extract the spec information and made web pages out of
> it.  I'm no fortune teller, but I'm pretty confident that spec information
> is guaranteed to end up in unexpected places as time goes on.
> 
> For that reason alone, a standardized way of representing that information
> is vital, imho...

hear, hear.  A couple weeks back, off list, I encouraged Jaco
on the XML sub-part, based on difficulties which I was seeing
in the 'Linux via RPM' project on spec files, and am pleased 
to see it in CVS.  


RPM has a couple of futures.  It can live in a shell which 
constrains it from growing, based on a preceived 'need' to 
support any and all prior .spec files of varying 
packager quality, or it can draw a line and say that a 
'well-formed' .spec file will be supported, and others may or 
may not work.

RPH is a lot of things, but first and foremost it is just a
package management system.  To pick a random victim, the
engrafted pre- and post- install scriptlets are contrary to
the prime purpose of reproducably defining the pristine
sources, and patches, and assembly 'recipe' to reliably,
tracably, and maintainably yield binaries with relevant
dependencies and 'provides' identified.

Reducing a .spec file into an XML grammar form is just another
step in more formally defining structure;  unversioned
internal (to the .specfile) scriptlets are more in the
direction of unmanaged entropy.  

Under the RPM model, a prefered 'scriptlet' method would be a
externally packaged script, similar to a patch file -- but 
clean removal issues are challenging.

-------------

Taking the time to clean up the 'grammar' of .spec files, 
through the discipline of a XML DTD has a couple of additional
benefits:

  1.  As stated, with a clear break in format, files which are
considered 'well-formed' by the translator will convert; 
others will break (hopefully) in a manner which suggests the 
needed patches to a 'man' page reading packager.

  2. The cpanflute/cpanflute2/etc variants are solutions to
specific problems posed by random perl modules and varying RPM
perl builds.  Rather than solving the problem incrementally
and repeatedly, the discipline of talking through the DTD will
(hopefully) allow the problem to be solved just once.

  3.  As Ed points out, it allows a future where automated
tools can emit well formed .spec files -- I am reminded of the
Tim Berners-Lee expectation; initially, that html would be
machine generated (as was its antecedent, SGML) -- 

He was surprised when it turned out that early HTML was hand
crafted (which was more a reflection of the immaturity of
tools to generate well formed html) -- CGI.pm, .php and other
approaches can yield nice tight .html; the early MS Word and
present day Outlook code is contrary painful to read.

Pushing .spec files into XML will allow 'solving' the 
automated generation issue, and moving on ...

-- Russ Herrold