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...

> Would you like to try for higher precision? RPM_UINT64_TYPE
> is available several years now, and gettimeofday(2) could
> be layered into a uint64_t for usec precision time stamps.
>
> The legacy issues with using RPM_UINT64_TYPE needs to be explored.
>
> I *think* that an added UINT64 tag has legacy compatibility for
> new tags that are not queried. At worst, there's a case that needs
> adding in a handful of places in older versions of rpm.

Hmmm... we at least should explore the possibility for higher
precisions through 64 bits here, of course. But I fear a little bit the
compatibility. Can RPM 4 still process those 64bit fields during the RPM
4 to RPM 5 upgrade?

> I'm also quite prepared for UINT128 to accomodate UUID's whenever.

For UUIDs one could already use their official string representation
just fine. The question is more: for what purpose would be wish to use
UUIDs instead? INSTALLTID could be a UUID v1 which is node and time
based. The time actually is of higher precision, too. So, we could
change INSTALLTID and ORIGINTID to a string type and put a UUID v1 into
it. This then would allow one to both determine with higher precision
what the time was _AND_ additional information about the host (its MAC
address, etc).

> BTW, its likely time to also substitute RPMTAG_INSTALLTID instead
> of RPMTAG_INSTALLTIME in --info spew. That likely pleases
> the greatest number of people's expectations.

As long as INSTALLTID is a _time_, yes. If you for instance convert it
into a UUID, no. So, I recommend to output BOTH: %{INSTALLTIME:date}
as the installation time and %{INSTALLTID:uuid} for the transaction
identifying UUID.

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com