On Feb 1, 2008, at 2:17 PM, Ralf S. Engelschall wrote:

>
> Also keep in mind the use case where UUIDs are maximum interesting: if
> one have to create IDs in a _DISTRIBUTED_ or _OFFLINE_ environment and
> at the same time have to ensure that once one would merge data  
> based on
> those IDs one does not get a conflict at the central merging place.
> I don't know whether such a situation also exists for RPM, but that's
> at least for what UUIDs are maximum interesting.
>

_OFFLINE_ is basically the --rebuilddb case. Once a rpmdb is closed,
one is in the _OFFLINE_ state, and there is no guarantee that the header
instance (which is the retrieval key for /var/lib/rpm/Packages) is  
meaningful
because --rebuilddb may have been performed.

> A theoretical use case could be: you want to merge two RPMDBs with all
> their records. Then it makes a lot of sense to already use UUIDs  
> for the
> keys in each RPMDB as once one have to merge multiple RPMDBs one can
> avoid conflicts without having to use a central ID issuer already  
> in the
> first place.
>

Similar to merging, having, say, srpm and rpm headers in the same db
to have a UUID key identify whether source/binary header sounds  
feasible.

There are many other cases where distinct, non-overlapping, subsets
might still be usefully stored in a single rpmdb, like with multilib, or
vendor, or other arbitrary groupings. I'm sure that some of the 60
bits of time stamp could be salted.

Montonically increasing UUIDv1 sounds like it has all the necessary
properties. Lord knows that saving a counter as header instance 0
in /var/lib/rpm/Packages is obscure.

Certainly more thought is needed. Thanks for the cogent reply -- I
have yet to look at UUID's in detail.

73 de Jeff