On Feb 1, 2008, at 7:50 AM, Ralf S. Engelschall wrote:

> On Fri, Feb 01, 2008, Jeff Johnson wrote:
>
>> On Feb 1, 2008, at 2:28 AM, Ralf S. Engelschall wrote:
>>> On Thu, Jan 31, 2008, Jeff Johnson wrote:
>>>
>>>> Poifect! That also keeps TID's opaque in case something
>>>> other than a time stamp ever has to be substituted: any
>>>> monotonically increasing integer would do for a transaction id.
>>>
>>> Ok, comitted so far. Now let's think about further improving it...
>>
>> Committed, but _NOW_, not later, is the time to decide higher  
>> precision
>> time types for newly added tags. Next month is likely already too  
>> late,
>> packages will exist
>> with a uint32_t type ...
>
> Yes, of course. ORIGINTIME and ORIGINTID are not the problem,
> as they are new. But what about INSTALLTIME and INSTALLTID?
> They already exists since years with a 32bit type...
>

I can change both INSTALLTIME and INSTALLTID to be
arrays of 2 int32's, adding tv_usecs, without incurring any legacy  
afaik.

Checking he->c for 2 instead of 1 will differentiate new from old.

I'd likely add a header extension for INSTALLTIME/INSTALLTID, and set  
tv_usecs to 0
for legacy tags, so that the compatibility issue can be buried deeply  
in exactly one
place. Neither INSTALLTIME/INSTALLTID is used in *.rpm headers.  
REMOVETID
is added with --repackage, but that's more to poison repackaged  
packaging
than for any other reason.

So shall I extend time stamps to 2 int32's? The array in  
RPMTAG_FILEMTIMES
is the only complexity, and it can be left untouched, or doubled in size
with the tv_secs fields following the tv_secs fields, likely without  
compatibility
issues.

I shall probably add some RPM_UINT64_TYPE tag that is normally disabled
to make it easier to detect compatibility issues, but that's a  
separate agenda
than changing to higher precision time stamps imho.

>> [...]
>> Its time to deploy an 64bit integer representation in rpm headers
>> imho. Its not rocket science to multiply a count by 8 instead of 4
>> where needed. And there are certainly usage cases for int64 types.
>> [...]
>
> What are you planning to use for the implementation? The C99 "long
> long" type or a custom type? Ask because for OSSP uuid I solved this
> portability problem by implementing an own little "64-bit arithmentic
> library": http://cvs.ossp.org/fileview?f=ossp-pkg/ui64/ui64.c&v=1.9
>

I carefully started using "long long" several years ago, have yet
to hear of portability problems. So likely C99.

Thanks for the ptr to the 64 bit arithmetic library.

> This libray could be also easily changed to also do 128 bit  
> arithmentic
> which cannot be done with any C standard type. And this way one is
> able to work with 64 and 128 bit integer values in a fully portable
> way, although one has to call functions for the arithmentic operations
> instead of the C level operators, of course.
>

rpm also has several MPI implementions linked already. My favorite is  
still
beecrypt, with its 32/64 "native endian" mpw_t, which I still think
is the prettiest, easiest, and (when optimized) highest performing  
MPI library around.