From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16629 invoked by uid 1002); 28 Jun 2003 23:00:52 -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 18301 invoked from network); 28 Jun 2003 23:00:51 -0000 Date: Sat, 28 Jun 2003 22:59:52 -0000 To: , "James Yonan" From: "James Yonan" X-Mailer: TWIG 2.7.7 Message-ID: In-Reply-To: <1056836979.14725.58.camel@nosferatu.lan> References: <20030628091853.GD11566@inventor.gentoo.org> , <20030628091853.GD11566@inventor.gentoo.org> , Cc: "Michael Kohl" , "Gentoo-Dev" Subject: Re: [gentoo-dev] The problem of stable/current. Was: Re: [gentoo-dev] the vision for Gentoo X-Archives-Salt: ff0194fb-77ba-4ef0-a2a7-4222cfcafa26 X-Archives-Hash: 5a1fc558e4eb7ff1de6c01694da04ebb 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