From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10996 invoked by uid 1002); 28 Jun 2003 21:32:40 -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 18568 invoked from network); 28 Jun 2003 21:32:40 -0000 Date: Sat, 28 Jun 2003 21:31:45 -0000 To: "Michael Kohl" From: "James Yonan" X-Mailer: TWIG 2.7.7 Message-ID: In-Reply-To: <20030629012404.1ef768a4.citizen428@cargal.org> References: <20030628091853.GD11566@inventor.gentoo.org>, <20030628091853.GD11566@inventor.gentoo.org> Cc: Subject: [gentoo-dev] The problem of stable/current. Was: Re: [gentoo-dev] the vision for Gentoo X-Archives-Salt: dfb0ca9e-ad56-47da-a534-f042a6349569 X-Archives-Hash: 6a8d342f1127e97e617b55b076005c8b > > 3) How do we best implement this vision? > > I like the recent developments in this regard, namely the proposal for > the new managment structure and GLEPs (which as a formal way of > proposing new features for the distribution can do great things for > user-dev interaction). *But* another thing I'd like to see (which may > contradict some of my aforementioned thoughts), is Gentoo being a little > less of a moving target: clear definitions of goals for a certain > release, an easy to access roadmap (both should be taken care of by the > new managment structure), clear responsibility for package > maintainership (taken care of by herds I guess) and things like this. > > About how to achieve this I'm not quite sure, although the BSD way of > -stable/-current seems to be a viable solution to some of my issues, it > somehow doesn't feel "gentooish" to me. 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 :) Taking the idea further, a checkpoint file could be created as a snapshot of a distribution as it exists on a given machine, or it could be edited by a distribution maintainer to favor a more conservative or more experimental build, or you could extract a checkpoint that represents the gentoo portage tree cvs at a particular date and time. When you emerge gentoo on a particular machine, you could specify an optional checkpoint file, or select from a list of checkpoint files which have known properties such as Stable, Experimental, etc. Additionally, anyone could publish their own checkpoint file, and others could use it to build similar distributions for themselves. For example, someone with 400 days of uptime on a heavily used server would have a checkpoint file which would be potentially valuable for others seeking a very solid distribution. As far as the format of the checkpoint file is concerned, it would basically be a patch against a known, benchmark snapshot of the gentoo portage tree (expressed as a cvs tag), and would be presented in a way that would bring the power of diff, patch, and cvs (+ some of the distributed repository concepts that are coming out of bitkeeper) to bear on the problem of evolving, mutating, and merging distributions. There are other potential benefits to the checkpoint concept. Security updates could be released as patches to a distribution checkpoint, allowing stable users to get the minimal upgrade needed to implement the security fix, rather than forcing a total upgrade. This could help do away with an either-or stable or experimental designation, as there would be a set of published stable checkpoints, each with their own empirical history to back up their claims to stability. In a lot of respects, the current cvs organization of gentoo makes this a very straightforward concept, as a checkpoint simply becomes a patch against a particular known snapshot of the gentoo portage tree. So in the same way that people start with vanilla kernels and then add patches, so too could you start with a known gentoo benchmark release and then patch the distribution with a "distribution patch" to make something games-centric, embedded centric, stability-centric, etc. I tend to think of gentoo as being a kind of source code for defining distributions, and I think this concept fits in very nicely with Gentoo's meta-distribution character. In fact, I suspect that diffing, patching, and merging portage trees is something that is already commonly done with a distribution such as gentoo. My proposal would then be to make it more accessible, and better integrated. The goal would be to create the documentation and infrastructure so that someone could type "emerge search distributions" and get a list of different possible gentoo distributions. The implementation of this would require an expansion of the .ebuild file concept, so that a distribution checkpoint could be represented as an ebuild. In that sense ebuilds would become nested, i.e. a whole portage tree could be minimally encapsulated within one .ebuild file, where the portage tree would be represented as some known benchmark tree + a patch delta. Just some ideas... James -- gentoo-dev@gentoo.org mailing list