On Fri, Feb 12, 2010 at 04:24:05PM -0800, Zac Medico wrote:
> On 02/12/2010 01:38 PM, Brian Harring wrote:
> > On Fri, Feb 12, 2010 at 12:54:21PM -0800, Zac Medico wrote:
> >> Hi,
> >>
> >> I'm thinking about adding a UUID file in /var/db/pkg, for comparing
> >> installed packages to binary packages. We already have BINPKGMD5,
> >> but the problem with that is that the MD5 of a binary package
> >> changes when it's updated for package moves. A UUID would be
> >> assigned at build time and remain constant thereafter. We can use
> >> python's uuid.uuid4() function to generate a random UUID. Any
> >> suggestions for alternative approaches?
> > 
> > Purpose?
> > ~harring
> 
> If you build binary packages for installation on multiple systems,
> and periodically have to rebuild packages for various reasons
> (revdep-rebuild or whatnot), it makes it easier to know whether a
> particular system has the latest build installed. Then you can
> create a package set that reinstalls any installed packages that are
> not the latest build.
> 
> It's basically a catch-all for rebuilds that aren't tracked by other
> kinds of metadata yet. Eventually, we should introduce metadata to
> indicate when things need to be reinstalled, as discussed in this bug:
> 
>   https://bugs.gentoo.org/show_bug.cgi?id=192319
> 
> In the mean time, it's nice to have a catch-all for keeping systems
> synchronized with the latest builds. We may want to consider
> including it in the $PKGDIR/Packages file as a convenience for
> binhost users.

This gets nasty... you're basically talking about the rpm equivalent 
of EPOCH.

Not a fan of an adhoc UUID (especially since it'll become standard 
via portage doing it), but a *timestamp* for the build, labeled as 
such, gets you what you want and is usable for other things- detecting 
when to rebuild a scm package for example.

That route gets my vote, and should also address your intentions.
~harring