From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org)
by nuthatch.gentoo.org with esmtp (Exim 4.62)
(envelope-from <gentoo-dev+bounces-24336-garchives=archives.gentoo.org@gentoo.org>)
id 1HyUM1-0007tI-I3
for garchives@archives.gentoo.org; Wed, 13 Jun 2007 15:01:50 +0000
Received: from robin.gentoo.org (localhost [127.0.0.1])
by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l5DF0l8g018690;
Wed, 13 Jun 2007 15:00:47 GMT
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83])
by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l5DEwVd1014900
for <gentoo-dev@lists.gentoo.org>; Wed, 13 Jun 2007 14:58:33 GMT
Received: from seldon (c-67-171-130-60.hsd1.or.comcast.net[67.171.130.60])
by comcast.net (rwcrmhc13) with SMTP
id <20070613145829m1300abs58e>; Wed, 13 Jun 2007 14:58:29 +0000
Date: Wed, 13 Jun 2007 07:58:04 -0700
From: Brian Harring <ferringb@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
Message-ID: <20070613145804.GK5778@seldon>
References: <C29EC904-37E4-4487-97F6-46EB69DDD8AF@cilly.mine.nu> <20070612100139.GA4738@ferdyx.org> <466E772F.6010807@thefreemanclan.net> <20070612104641.GE4738@ferdyx.org> <AAC967D1-766E-46E1-9A0A-A1F2B3425F12@cilly.mine.nu> <4FA373CA-773E-4390-BD91-70F87510D6D9@cilly.mine.nu> <20070612132934.2e34b7d6@loki> <26924B32-9D3E-4B0D-B527-C90E5DBC8B82@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="SUk9VBj82R8Xhb8H"
Content-Disposition: inline
In-Reply-To: <26924B32-9D3E-4B0D-B527-C90E5DBC8B82@gentoo.org>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Archives-Salt: b4f33814-c38e-4669-b087-c4f1e4fe6177
X-Archives-Hash: afb4bcfdbc523b323e4b0c7d92104c4c
--SUk9VBj82R8Xhb8H
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 13, 2007 at 04:35:31PM +0200, Robert Buchholz wrote:
> The problem is rather that the patches are gone from the distfiles
> mirror after two weeks. The sources often stay upstream, but could
> also be gone.
>=20
> Is there an archive for these files I missed?
That archive ('purgatory' being the name used for it) isn't publically=20
accessible; had suggested it in the past, but infra folks didn't=20
think it would be needed.
Few issues if it were opened up;
1) it's not a true vcs, just a directory. Meaning=20
1.a) it's collapsing down the trees history of distfile names; if=20
ebuild x refs 'patch', gets removed, 'patch' goes into purgatory. If=20
ebuild y refs 'patch', which is a different file, then gets removed,=20
ebuild ys' version of 'patch' is whats is now in purgatory (last used=20
basically).
1.b) skimped a bit in the description above; 'patch' gets removed from=20
purgatory when ebuild 'y' is added to the tree- the chksums will=20
differ, thus it throws out the copy that no longer is relevant to it's=20
job (maintaining the mirror image).
2) if implemented, likely to be a single box- meaning stuff shouldn't=20
rely on it as an upstream URI, they should mirror it themselves.
3) mirror maintenance, if an ebuild is added to the tree that uses=20
that specific distfile name, as hinted at in 1.b, the file is removed=20
=66rom purgatory- this *includes* if the chksums match. Basically, if=20
the file is needed on the mirror image, it copies it over and wipes=20
the purgatory copy of it (intention is to keep space usage down).
This obviously would break any ebuilds daftly ignoring #2, and using=20
the purgatory host as an upstream URI.
Personally, I think at least for devs, having access to purgatory=20
would be a good thing. Folks seem to have learned over the last few=20
years, but dealt with a lot of requests where a dev screwed up and=20
needed to pull a file out of purgatory. Perhaps they've gotten wiser=20
since, dunno. Either way, if trying to pull a file out of=20
purgatory, bug your friendly infra monkey, or zmedico if you need a=20
specific file out- they ought to have access.
For effectively random anonymous, http/ftp, not sure about=20
that. Think some form of access is needed, don't think it should=20
really be usable as an upstream host.
~harring
--SUk9VBj82R8Xhb8H
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGcAX8siLx3HvNzgcRAv2OAJ0XA2I48l2LoZ1j1ZDR7TV4WUBbNgCglfRX
HBFVnY+lTxFbs7Cf7dyii78=
=uPY1
-----END PGP SIGNATURE-----
--SUk9VBj82R8Xhb8H--
--
gentoo-dev@gentoo.org mailing list