Re: [gentoo-portage-dev] add UUID for comparison of installed package to binary package?
On 02/14/2010 06:26 PM, Brian Harring wrote: > How about a more descriptive name... build_time or something similar. > Yes, CTIME means creation time, but I'd rather not overload terms that > have specific meanings already just for the sake of saving a few chars > in typing the filename in... > ~harring Ok, BUILD_TIME sounds good to me. -- Thanks, Zac
Re: [gentoo-portage-dev] add UUID for comparison of installed package to binary package?
On 02/14/2010 06:02 PM, Ned Ludd wrote: >> Ok, then how about a vdb entry named CTIME that contains an integer >> number of seconds since the unix Epoch? > > That would be UNIXTIME vs CTIME I'd think. I was alluding to the stat(2) st_ctime field, but I guess BUILD_TIME is probably more appropriate (as suggested by Brian). -- Thanks, Zac
Re: [gentoo-portage-dev] add UUID for comparison of installed package to binary package?
On Sun, Feb 14, 2010 at 06:02:28PM -0800, Ned Ludd wrote: > On Sun, 2010-02-14 at 12:11 -0800, Zac Medico wrote: > > On 02/14/2010 04:36 AM, Brian Harring wrote: > > > 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 > > > > Ok, then how about a vdb entry named CTIME that contains an integer > > number of seconds since the unix Epoch? > > That would be UNIXTIME vs CTIME I'd think. How about a more descriptive name... build_time or something similar. Yes, CTIME means creation time, but I'd rather not overload terms that have specific meanings already just for the sake of saving a few chars in typing the filename in... ~harring pgpTTyGjPY9W9.pgp Description: PGP signature
Re: [gentoo-portage-dev] add UUID for comparison of installed package to binary package?
On Sun, 2010-02-14 at 12:11 -0800, Zac Medico wrote: > On 02/14/2010 04:36 AM, Brian Harring wrote: > > 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 > > Ok, then how about a vdb entry named CTIME that contains an integer > number of seconds since the unix Epoch? That would be UNIXTIME vs CTIME I'd think.
Re: [gentoo-portage-dev] add UUID for comparison of installed package to binary package?
On 02/14/2010 04:36 AM, Brian Harring wrote: > 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 Ok, then how about a vdb entry named CTIME that contains an integer number of seconds since the unix Epoch? -- Thanks, Zac
Re: [gentoo-portage-dev] add UUID for comparison of installed package to binary package?
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 pgpQadYFVbGdp.pgp Description: PGP signature
