"Andreas Raab" <andreas.raab at gmx.de> wrote:
> > Incidentally, you *can* change package names without having the UUID. 
> > People do it in Debian by having a transition period where 
> > both packages are present and the new one "provides" the other
> > one.  It's more than trivial, but it's still not that big of a deal.
> > The nice thing is that all the tools can just immediately display
> > and modify package names, instead of having to look up in some
> > global table what all the UUID's mean.
> 
> Err, excuse me, but why can't you have both? Seems to me that something like
> a 'named object' might contain both, name and uuid (what a concept, eh? ;)
> Then, you can stick all the logic you want into this guy and live on happily
> ever after.
> 

I don't understand.  The issue is what a Package object will look like. 
It will refer to other packages by reference in its dependency
information.  What should this reference look like?  A human-readable
name, or a UUID?  The advantage of a UUID is that there is never
pressure to change it.  The advantage of a human-readable name is that
the tools are simpler.  After all, surely humans are never going to look
at the UUID's directly, but that means spiffier tools if you are using
UUID's.

What would it mean to have a reference with both a UUID and a name?  How
do you perform the dereference when you are ready to download the real
package object?


Lex