From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18843 invoked by uid 1002); 29 Jun 2003 10:03:06 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 10195 invoked from network); 29 Jun 2003 10:03:02 -0000 From: Martin Schlemmer Reply-To: azarah@gentoo.org To: James Yonan Cc: Michael Kohl , Gentoo-Dev In-Reply-To: References: <20030628091853.GD11566@inventor.gentoo.org> , <20030628091853.GD11566@inventor.gentoo.org> , Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Cuju1haydrXDbyej46yg" Organization: Message-Id: <1056881036.17929.4.camel@nosferatu.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 29 Jun 2003 12:03:57 +0200 Subject: Re: [gentoo-dev] The problem of stable/current. Was: Re: [gentoo-dev] the vision for Gentoo X-Archives-Salt: c2f8acb6-c3b2-4544-a8ce-929fddc0a1b5 X-Archives-Hash: 8720b2da9ec8cedb3a0e1749f921ddae --=-Cuju1haydrXDbyej46yg Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2003-06-29 at 00:59, James Yonan wrote: > Martin Schlemmer said: >=20 > > On Sat, 2003-06-28 at 23:31, James Yonan wrote: > >=20 > > > Just to throw out an idea on creating a generalization to stable/curr= ent (I'm > > > new to Gentoo, so I'm not sure how much of this has already been done= , or to > > > what extent these ideas have already been made concrete in the portag= e > concept). > > >=20 > > > Why not create a notion of a distribution "checkpoint"? > > >=20 > > > A checkpoint is a file that contains all information necessary to bui= ld a > > > particular gentoo distribution as it existed at some point in time, s= imilar to > > > the idea of a cvs tag, or saving the game before you do something tha= t's > > > likely to get you killed :) > >=20 > > Unfortunately a big problem with this, is that ebuild do not stick > > around long enouth ... except of course if you do it your side. > >=20 > > IMHO, I do not see that we can do it with current implementation > > of the portage tree, even if we do not cleanup stuff - as if we > > do not, the tree is going to get *too* big. >=20 > Well, the idea would be to manage the size by having a benchmark portage = tree > and then representing a custom tree inside an .ebuild file by taking the > benchmark portage tree reference + one or more patch deltas. The > "distribution ebuild" file would really not be large, as it would contain > little more than tags, references, and patches, just as standard ebuild f= iles > exist today for packages. Since cvs already manages repository size by > representing changes as deltas, I doubt a cvs explosion would be likely. = The > real win with cvs (or other versioning tools) is the way in which tags ca= n be > locked to constant snapshots of the tree which are invariant over the lif= etime > of the repository. This constancy is important because it provides a sol= id > foundation against which patch deltas can be derived, and would therefore > allow a particular gentoo snapshot (as represented by a patch against a c= vs > tag) to be accessible indefinitely, leveraging the versioning capability = of > cvs to prevent explosions in size and complexity. >=20 Well, sure, if we can do that from where it is migrated from cvs to the=20 rsync servers. We have gone into before, and it will make things too complex in trying to have one ebuild file, but multiple versions. --=20 Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa --=-Cuju1haydrXDbyej46yg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA+/rmMqburzKaJYLYRAgRdAJ9cOmNZcolf1U/8oDJByakZpfNGoACfWzdT ApN+1brGnBKq9iR3TDEcRVA= =Hiqs -----END PGP SIGNATURE----- --=-Cuju1haydrXDbyej46yg--