From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-34247-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1LWXxt-0003sm-2i
for garchives@archives.gentoo.org; Mon, 09 Feb 2009 15:22:29 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 5DA7BE029D;
Mon, 9 Feb 2009 15:22:26 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id 19D7AE029D
for <gentoo-dev@lists.gentoo.org>; Mon, 9 Feb 2009 15:22:26 +0000 (UTC)
Received: from [192.168.0.100] (227-81.3-85.cust.bluewin.ch [85.3.81.227])
(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
by smtp.gentoo.org (Postfix) with ESMTP id CD4E6655EE
for <gentoo-dev@lists.gentoo.org>; Mon, 9 Feb 2009 15:22:24 +0000 (UTC)
Subject: Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache
validation
From: Tiziano =?ISO-8859-1?Q?M=FCller?= <dev-zero@gentoo.org>
To: gentoo-dev@lists.gentoo.org
In-Reply-To: <498E17E6.8060407@gentoo.org>
References: <498758E6.5080609@gentoo.org>
<1234045916.24784.1373.camel@localhost> <498E17E6.8060407@gentoo.org>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-O1VwjrVxEpbTG3BkYv56"
Organization: Gentoo
Date: Mon, 09 Feb 2009 15:22:20 +0000
Message-Id: <1234192940.18160.1011.camel@localhost>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
Mime-Version: 1.0
X-Mailer: Evolution 2.24.4
X-Archives-Salt: f0c8407c-3908-4b45-b694-0bf38cd4a4db
X-Archives-Hash: 8f8c5727d233588b95374f9cf86619e1
--=-O1VwjrVxEpbTG3BkYv56
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Am Samstag, den 07.02.2009, 15:23 -0800 schrieb Zac Medico:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Tiziano M=C3=BCller 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.
>=20
> 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:
>=20
> SHA1 02021be38b a28b191904 3992945426 6ec21b29a3
>=20
> >> 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?
>=20
> 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].
>=20
> [1] http://github.com/funtoo/portage/tree/master
Ok, after having the technical details discussed, I'd like to know which
overlays or trees could really make use of it.
Because small overlays surely won't generate the metadata because it is
cumbersome to generate the metadata and isn't really a speed issue.
Most larger overlays/repositories will probably be able to setup rsync
or implement a procedure using cron+tarball.
So, who exactly is asking about being able to distribute the metadata
cache via a VCS?
--=20
=EF=BB=BF-------------------------------------------------------
Tiziano M=C3=BCller
Gentoo Linux Developer, Council Member
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin
E-Mail : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30
--=-O1VwjrVxEpbTG3BkYv56
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Dies ist ein digital signierter Nachrichtenteil
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEABECAAYFAkmQSiwACgkQGwVqY66cHjD3cACdFHu1ieIS/2cKDACtpO7JxDzn
9dMAn1j56AYsA57LkkBc0rHciGW0DYnd
=Nk9A
-----END PGP SIGNATURE-----
--=-O1VwjrVxEpbTG3BkYv56--