On May 14, 2008, at 8:13 AM, Ralf S. Engelschall wrote:

>
> No, not just the 60 bit of the time is used! MD5 hashes are 128 bit
> in size and they are all stored into the UUID except for the few bits
> of the UUID branding. SHA-1 hases are 160 bit in size and are clipped
> (first bytes) to the first 128 bit for storing into a UUID.
>

OK so the transform MD5 => UUIDv3 has no inverse because of UUID  
branding bits.

Which also means that there are fewer than 128 (and more than 60)  
bits that
are available if the UUID branding fields are avoided, and that there  
is a convention
to custom brand UUID's.

That's what I needed to confirm. Thanks.

>
>> 4) The design of the URI hierarchical name space (for a package  
>> cache,
>> or more generally, for *.rpm metadata) likely needs more thought than
>> the backing store, or using UUID's as primary keys. Any thoughts?
>
> Here I've to admit that I still cannot say anything as I've not  
> closely
> followed all your mails related to this. If you can summarize in more
> detail what exactly you want to implement and how you at least plan to
> implement it I can give you some feedback on this, of course.
>

I want to attach a protocol and data store to RPMTAG_DISTURL as  
originally
planned here:

     http://www.redhat.com/archives/rpm-list/2002-May/msg00031.html

Note: there's no real reason any more to use RPMTAG_DISTURL, any
arbitrary tag could  be used to save one (or more) URI's. But there  
may still
be legacy reasons to use exactly RPMTAG_DISTURL as proposed.

The simplest usage case I can describe is disaster recovery after
     rm -rf /var/lib/rpm

(aside) There's _STILL_ no way to automagically and easily recreate  
an rpmdb given
URI's to the packages that were installed that I'm aware of 6+ years  
later.

Instead of (or in addition to) saving N-V-R.A.rpm in /var/log/ 
rpmpkgs, I'd
like to add RPMTAG_PKGUUID (a UUIDv5 based on a namespace
string (see below) of the header+payload MD5 retrieved as  
RPMTAG_PKGID) as
a disaster recovery mechanism.

The protocol could be a simple HTTP POST to some URI of the pkg  
UUID's returning
URI's to the desired packages so that an rpmdb can be recreated using  
--justdb.

There are two URI design issues hidden in the above:

1) the RPMTAG_PKGUUID (atm, easily changed) is being generated from the
concatenation of "http://rpm5.org/" and the header+payload MD5 hex  
string. I'd
like more generality, duh.

2) providing some structural hints (and ideally a working example  
that is easy to
configure at a website) of the URI to send the POST to.

For lack of better technical vocabulary, I'll call the URI in 1) the  
"namespace URI", and
the URI in 2) the "web URI", I'm sure you understand the distinction.

Ideally I'd also like tag content addressable structure within both  
the namespace/web URI's
so that the feeble preliminary implementation in, say, /etc/rpm/ 
sysinfo/Requirename cn
be easily embedded into both the namespace and web URI by concatenating.

Have I described what I'm looking for with a "URI hierarchical name  
space" sufficiently well?

73 de Jeff