add UUID for comparison of installed package to binary package?
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAkt1v/sACgkQ/ejvha5XGaN96ACg20x9kIr6CxAbWxlxqub3XkY7
7skAnRH3FdZqQs+v9EePrqFwztGSpHt2
=C7Dx
-----END PGP SIGNATURE-----

add UUID for comparison of installed package to binary package?
 

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

add UUID for comparison of installed package to binary package?
 

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.
--
Thanks,
Zac

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

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

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

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

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