public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Zac Medico <zmedico@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
Date: Sat, 07 Feb 2009 15:23:18 -0800	[thread overview]
Message-ID: <498E17E6.8060407@gentoo.org> (raw)
In-Reply-To: <1234045916.24784.1373.camel@localhost>

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

Tiziano Müller wrote:
> Am Montag, den 02.02.2009, 12:34 -0800 schrieb Zac Medico:
>> For the digest format, I suggest that we use the leftmost 10
>> hexadecimal digits of the SHA-1 digest. The rationale for limiting
>> it to 10 digits (out of 40) is to save space. Due to the avalanche
>> effect [2], 10 digits should be sufficient to ensure that problems
>> resulting from hash collisions are extremely unlikely.
> I'd recommend to prefix the digest with a "{TYPE}" (like for hashed
> passwords) to be able to change the digest algorithm as needed
> (especially in regards to the current SHA successor competition).
> This allows a future package manager which might use SHA-3 for hashing
> (once it's released) to still check old digests. Furthermore it would
> allow for easier transition and only needs a definition of allowed
> hashes instead of a specific one.

I like that idea. That way it's not necessary to bump the EAPI in
order to change the hash function. So, a typical DIGESTS value might
look like this:

SHA1 02021be38b a28b191904 3992945426 6ec21b29a3

>> The primary reason to use a digest for cache validation instead of a
>> timestamp is that it allows the cache validation mechanism to work
>> even if the tree is distributed with a protocol that does not
>> preserve timestamps, such as git or subversion. This would make it
> Well, usually you don't keep intermediate or generated files in a VCS,
> so why the metadata?

People who distribute overlays commonly ask if it's possible to
distribute metadata cache with the overlay. Using a format that
doesn't rely on timestamps will allow them to distribute metadata
cache using their existing infrastructure, which is typically git or
subversion. In addition to overlays, it would also be useful for
forks of the entire gentoo tree, such as the funtoo tree [1].

[1] http://github.com/funtoo/portage/tree/master
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmOF+UACgkQ/ejvha5XGaPSyQCg7kVF3S1z4G+7pXOrLBB1Pu77
Y5cAnj60bGSww8SLfcqhHmk1voKwm20+
=PmlJ
-----END PGP SIGNATURE-----



  reply	other threads:[~2009-02-07 23:22 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-02 20:34 [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation Zac Medico
2009-02-06  9:55 ` [gentoo-dev] " Markus Ullmann
2009-02-07  1:13   ` Zac Medico
2009-02-07 22:31 ` [gentoo-dev] " Tiziano Müller
2009-02-07 23:23   ` Zac Medico [this message]
2009-02-08  8:07     ` Tiziano Müller
2009-02-08  8:59       ` Zac Medico
2009-02-08 11:51         ` Tiziano Müller
2009-02-08 20:36           ` Zac Medico
2009-02-08 21:48             ` Tiziano Müller
2009-02-08 22:14               ` Zac Medico
2009-02-08 22:18     ` Ciaran McCreesh
2009-02-08 22:43       ` Zac Medico
2009-02-08 22:47         ` Ciaran McCreesh
2009-02-08 23:03           ` Zac Medico
2009-02-08 23:10             ` Ciaran McCreesh
2009-02-08 23:27               ` Zac Medico
2009-02-08 23:30                 ` Ciaran McCreesh
2009-02-08 23:40                   ` Zac Medico
2009-02-09 12:30                     ` Petteri Räty
2009-02-09 13:59                       ` Ciaran McCreesh
2009-02-09 14:15                         ` Petteri Räty
2009-02-09 14:18                           ` Ciaran McCreesh
2009-02-09 14:21                           ` Rémi Cardona
2009-02-09 20:19                       ` Zac Medico
2009-02-09 18:43         ` Ciaran McCreesh
2009-02-09 20:02           ` Zac Medico
2009-02-09 15:22     ` Tiziano Müller
2009-02-09 19:55       ` Zac Medico
2009-02-10 12:20         ` Brian Harring
2009-02-10 12:52           ` Nirbheek Chauhan
2009-02-10 20:55           ` Zac Medico
2009-02-11  9:00             ` Brian Harring
2009-02-11 10:01               ` Zac Medico
2009-02-14 13:18                 ` Brian Harring
2009-02-14 20:16                   ` Zac Medico
2009-02-15 22:51     ` Zac Medico
2009-02-15 23:15       ` Ciaran McCreesh
2009-02-15 23:26         ` Zac Medico
2009-02-15 23:30           ` Ciaran McCreesh
2009-02-15 23:56             ` Zac Medico
2009-02-16  0:06               ` Ciaran McCreesh
2009-02-16  0:48                 ` Zac Medico
2009-02-16  0:53                   ` Ciaran McCreesh
2009-02-16  0:54                   ` Zac Medico

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=498E17E6.8060407@gentoo.org \
    --to=zmedico@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox