My last check-in changes the prototype for headerGetExtension().

Before argument 4 was a "void *".

Now arg4 is a "a hRet_t *".

In both cases the same addresses, and the same data, is returned  
everywhere as before.
(aside) Well, I may still have screwed something in the  
implementation, but ...

However, there are now numerous warnings that, indeed, "void *" is  
changing
to "hRET_t *" everywhere.

If someone does wish to remove warnings, he fix is more than adding a  
cast.
See an example in what I just checked in. In fact adding a cast will  
likely cause
me to miss a conversion somewhere, so please don't just add (hRET_t  
*) casts.

I have several goals with using headerGetExtension():

1) merge header extensions and header tags
       Header tags appear in packages, header extensions do not.

2) eliminate headerFreeData() everywhere.
       Retrieving tags with integer types returns a pointer to data
       directly within a header, making memory management quite
       a bit more complicated than useful. There's the additional
       need to byte swap all integer data directly in header memory,
       which can/will change data undermeath other accesses on the same
       header.

3) add support for arbitrary tags
       Technically, rpm HEAD already has support for arbitrary tags,
        its just that the expectation is that rpm will somehow interpret
        "arbitrary" as what the luser intended. There's also no easy
        way to retrieve arbitrary tags atm, headerGetExtension will
        be part of the arbitrary tag retrieval implementation.

4) type coercion
       The data typing in rpm is rather bizzarre. E.g. RPMTAG_ARCH  
started
        life as a RPM_INT32_TYPE, but is currently a RPM_STRING_TYPE.
        Any change of data type necessitates handling old <-> new  
conversions,
        and this is currently done in multiple places inline rather  
than in one place.

5) metatag containers
       One of the problems with rpm metadata is that there's too many  
datum's and
       no pleasant abstractions (other than a single dimension  
array). RPMTAG_NVRA
       is a concatenation of the N, V, R, and A tags into a metatag  
container. There are
       other generalizations that need to happen as well, like  
RPMTAG_STAT to
       return an array of stat(2) structures built from header meta- 
data.

6) (possibly) table driven header retrieval
       ATM, all tag retrieval is method driven for a single tag, mostly
       because headerGetEntry() (and the headerGetExtension()  
generalization)
       have multiple arguments. I may switch headerGetExtension  
arguments to
       use a HE_t * ptr instead, whereupon retrieving multiple tags,  
not just a single
       tag, becomes feasible.

Enjoy!