Gentoo Archives: gentoo-dev

From: James Yonan <jim@×××××.net>
To: Michael Kohl <citizen428@××××××.org>
Cc: gentoo-dev@g.o
Subject: [gentoo-dev] The problem of stable/current. Was: Re: [gentoo-dev] the vision for Gentoo
Date: Sat, 28 Jun 2003 21:32:40
In Reply to: Re: [gentoo-dev] the vision for Gentoo by Michael Kohl
1 > > 3) How do we best implement this vision?
2 >
3 > I like the recent developments in this regard, namely the proposal for
4 > the new managment structure and GLEPs (which as a formal way of
5 > proposing new features for the distribution can do great things for
6 > user-dev interaction). *But* another thing I'd like to see (which may
7 > contradict some of my aforementioned thoughts), is Gentoo being a little
8 > less of a moving target: clear definitions of goals for a certain
9 > release, an easy to access roadmap (both should be taken care of by the
10 > new managment structure), clear responsibility for package
11 > maintainership (taken care of by herds I guess) and things like this.
12 >
13 > About how to achieve this I'm not quite sure, although the BSD way of
14 > -stable/-current seems to be a viable solution to some of my issues, it
15 > somehow doesn't feel "gentooish" to me.
17 Just to throw out an idea on creating a generalization to stable/current (I'm
18 new to Gentoo, so I'm not sure how much of this has already been done, or to
19 what extent these ideas have already been made concrete in the portage concept).
21 Why not create a notion of a distribution "checkpoint"?
23 A checkpoint is a file that contains all information necessary to build a
24 particular gentoo distribution as it existed at some point in time, similar to
25 the idea of a cvs tag, or saving the game before you do something that's
26 likely to get you killed :) Taking the idea further, a checkpoint file could
27 be created as a snapshot of a distribution as it exists on a given machine, or
28 it could be edited by a distribution maintainer to favor a more conservative
29 or more experimental build, or you could extract a checkpoint that represents
30 the gentoo portage tree cvs at a particular date and time. When you emerge
31 gentoo on a particular machine, you could specify an optional checkpoint file,
32 or select from a list of checkpoint files which have known properties such as
33 Stable, Experimental, etc. Additionally, anyone could publish their own
34 checkpoint file, and others could use it to build similar distributions for
35 themselves. For example, someone with 400 days of uptime on a heavily used
36 server would have a checkpoint file which would be potentially valuable for
37 others seeking a very solid distribution.
39 As far as the format of the checkpoint file is concerned, it would basically
40 be a patch against a known, benchmark snapshot of the gentoo portage tree
41 (expressed as a cvs tag), and would be presented in a way that would bring the
42 power of diff, patch, and cvs (+ some of the distributed repository concepts
43 that are coming out of bitkeeper) to bear on the problem of evolving,
44 mutating, and merging distributions.
46 There are other potential benefits to the checkpoint concept. Security
47 updates could be released as patches to a distribution checkpoint, allowing
48 stable users to get the minimal upgrade needed to implement the security fix,
49 rather than forcing a total upgrade.
51 This could help do away with an either-or stable or experimental designation,
52 as there would be a set of published stable checkpoints, each with their own
53 empirical history to back up their claims to stability.
55 In a lot of respects, the current cvs organization of gentoo makes this a very
56 straightforward concept, as a checkpoint simply becomes a patch against a
57 particular known snapshot of the gentoo portage tree. So in the same way that
58 people start with vanilla kernels and then add patches, so too could you start
59 with a known gentoo benchmark release and then patch the distribution with a
60 "distribution patch" to make something games-centric, embedded centric,
61 stability-centric, etc.
63 I tend to think of gentoo as being a kind of source code for defining
64 distributions, and I think this concept fits in very nicely with Gentoo's
65 meta-distribution character. In fact, I suspect that diffing, patching, and
66 merging portage trees is something that is already commonly done with a
67 distribution such as gentoo. My proposal would then be to make it more
68 accessible, and better integrated. The goal would be to create the
69 documentation and infrastructure so that someone could type "emerge search
70 distributions" and get a list of different possible gentoo distributions. The
71 implementation of this would require an expansion of the .ebuild file concept,
72 so that a distribution checkpoint could be represented as an ebuild. In that
73 sense ebuilds would become nested, i.e. a whole portage tree could be
74 minimally encapsulated within one .ebuild file, where the portage tree would
75 be represented as some known benchmark tree + a patch delta.
77 Just some ideas...
79 James
82 --
83 gentoo-dev@g.o mailing list