From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10362 invoked by uid 1002); 29 Jun 2003 11:13:46 -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 15074 invoked from network); 29 Jun 2003 11:13:46 -0000 Date: Sun, 29 Jun 2003 07:13:22 -0400 From: Michael Cummings To: "James Yonan" Cc: "Gentoo-Dev" Message-Id: <20030629071322.4284d463.mcummings@gentoo.org> In-Reply-To: References: <20030628091853.GD11566@inventor.gentoo.org> <20030628091853.GD11566@inventor.gentoo.org> Organization: Gentoo X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.,K(PBDQATGwR(W" Subject: Re: [gentoo-dev] The problem of stable/current. Was: Re: [gentoo-dev] the vision for Gentoo X-Archives-Salt: 5b692d4e-1c5f-4dbf-822e-bb6d2d9bf7cc X-Archives-Hash: 10b26a9cf7cd2d25ccad72d5d23aef35 --=.,K(PBDQATGwR(W Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Not to be a nay sayer, because I like the idea of a stable tree, but one hitch is that in our current setup, we pull source from the source, but sometimes those source packages go away - hence the new ebuild. Not a universal, just pointing it out (happens in dev-perl/* for instance). Just sharing, Mike On Sat, 28 Jun 2003 22:59:52 -0000 "James Yonan" wrote: > Martin Schlemmer said: > > > On Sat, 2003-06-28 at 23:31, James Yonan wrote: > > > > > Just to throw out an idea on creating a generalization to stable/current (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 portage > concept). > > > > > > Why not create a notion of a distribution "checkpoint"? > > > > > > A checkpoint is a file that contains all information necessary to build a > > > particular gentoo distribution as it existed at some point in time, similar to > > > the idea of a cvs tag, or saving the game before you do something that's > > > likely to get you killed :) > > > > Unfortunately a big problem with this, is that ebuild do not stick > > around long enouth ... except of course if you do it your side. > > > > 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. > > 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 files > 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 can be > locked to constant snapshots of the tree which are invariant over the lifetime > of the repository. This constancy is important because it provides a solid > foundation against which patch deltas can be derived, and would therefore > allow a particular gentoo snapshot (as represented by a patch against a cvs > tag) to be accessible indefinitely, leveraging the versioning capability of > cvs to prevent explosions in size and complexity. > > I really do believe that the holy grail of meta-distributions is to achieve > the representation of an entire distribution in a compact, textual form, > allowing the tools of open source development (diff, patch, cvs, etc.) to be > applied to the distribution tree itself, and allowing the distribution to > evolve along different lines of evolution, but having the tools to keep the > different versions in sync. > > Take, for example, the linux kernel. A quick glance at kernel.org shows a > whole bunch of kernels, 10 to be exact. Many of them are simply someone's > personal selection of patches, appended with their initials. But these 10 > versions are not true forks, they are only alternative versions of the same > overall evolutionary progression. It's really the power of the versioning > tools, i.e. cvs, bitkeeper, etc. that gives us the ability to fork and then > remerge, making the forks ephemeral rather than irreconcilable, and preserving > an overall singularity of evolution even within an environment where multiple, > distributed repositories exist. > > My idea is simply to take the _concept_ of cvs, bitkeeper, and distributed > versioning repositories as it is used in linux kernel development, and apply > it to making a true meta-distribution of gentoo. To the extent that the > portage tree concept is really a kind of source code for developing > distributions, and the fact that distributed development tools like diff, > patch, and cvs are already quite mature, I believe that it's not such a big > leap from concept to implementation. > > James > > > -- > gentoo-dev@gentoo.org mailing list -- -----o()o--------------------------------------------- | #gentoo-dev on irc.freenode.net Gentoo Dev | #gentoo-perl on irc.freenode.net Perl Guy | | GnuPG Key ID: AB5CED4E9E7F4E2E -----o()o--------------------------------------------- --=.,K(PBDQATGwR(W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+/snSq1ztTp5/Ti4RAq6SAJ43pj5Y+w05gp0ok+0hC26N9ZvlpwCdF+QI 9KAKrqzcmwsig0RCCgxr6YU= =rpUN -----END PGP SIGNATURE----- --=.,K(PBDQATGwR(W--