RPM Community Forums

Mailing List Message of <rpm-devel>

Eliminating RPM_CHAR_TYPE (and other unimplemented types).

From: Jeff Johnson <n3npq@mac.com>
Date: Wed 07 Nov 2007 - 15:35:37 CET
Message-Id: <628A9F09-383C-490B-B91D-FD8CEAEA435E@mac.com>
Several tag data types have never been used (RPM_CHAR_TYPE),
or implemented (RPM_NULL_TYPE), and are headed for the bit bucket.

At the same time, I'm likely going to add implicit typing of existing  
tags
using the autogenerated triples {"name", number, type} entries in  
rpmdb/tagtbl.c,
none of the tag data types have changed in years. I'll add an assertion
to insure that the table agrees with the rpm code for a week or so  
before removing.

At that point, rpm-5.0 is well positioned for doing type coercion, as  
well as
adding support for new/arbitrary tag data types. Any additional types  
will
be coerced into RPM_BIN_TYPE within a *.rpm for legacy compatibility.

Any suggestions for other new data types?

On my short list are:

1) Adding a associative array data ttype.
    rpm already has RPM_I18NSTRING_TYPE as an associative array, but
    the implementation is so arcane it hurts.

     Basically, two tag arrays are associated, the first as index,  
the second
     as value. A one-of-N lookup proceeds by finding the key in the  
index tag,
     and returning same entry from the value tag.

     As currently implemented in RPM_I18NSTRING_TYPE, locale is used as
     implicit key, and both the index and value tags are strings. The  
generalization
     is rather obvious.

2) Adding hex/base64 transforms.
     Headers cannot currently represent an array of variable length  
octets. Converting
     to hex or base64 encoding solves the representation problem  
(there's still the
     issue of how to pass octet lengths).

3) Dictionary lookup.
     For compactness, some strings are uniqified in one tag array,  
and then indexed
     from another tag array. The technique is quite powerful and  
leads to overall reduction
    of redundant content.

4) Well formedness constraints on values.
     Certain tags have additional well-formedness constraints, like  
parseable
     as hex, or composed of RFC-2440 packates, that cannot currently  
be tested
     because the goop is just dumped into RPM_BIN_TYPE octets.

73 de Jeff

  
    
Received on Wed Nov 7 15:36:12 2007
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.