Gentoo Archives: gentoo-dev

From: James Yonan <jim@×××××.net>
To: azarah@g.o, James Yonan <jim@×××××.net>
Cc: Michael Kohl <citizen428@××××××.org>, Gentoo-Dev <gentoo-dev@g.o>
Subject: Re: [gentoo-dev] The problem of stable/current. Was: Re: [gentoo-dev] the vision for Gentoo
Date: Sat, 28 Jun 2003 23:00:52
In Reply to: Re: [gentoo-dev] The problem of stable/current. Was: Re: [gentoo-dev] the vision for Gentoo by Martin Schlemmer
1 Martin Schlemmer <azarah@g.o> said:
3 > On Sat, 2003-06-28 at 23:31, James Yonan wrote:
4 >
5 > > Just to throw out an idea on creating a generalization to stable/current (I'm
6 > > new to Gentoo, so I'm not sure how much of this has already been done, or to
7 > > what extent these ideas have already been made concrete in the portage
8 concept).
9 > >
10 > > Why not create a notion of a distribution "checkpoint"?
11 > >
12 > > A checkpoint is a file that contains all information necessary to build a
13 > > particular gentoo distribution as it existed at some point in time, similar to
14 > > the idea of a cvs tag, or saving the game before you do something that's
15 > > likely to get you killed :)
16 >
17 > Unfortunately a big problem with this, is that ebuild do not stick
18 > around long enouth ... except of course if you do it your side.
19 >
20 > IMHO, I do not see that we can do it with current implementation
21 > of the portage tree, even if we do not cleanup stuff - as if we
22 > do not, the tree is going to get *too* big.
24 Well, the idea would be to manage the size by having a benchmark portage tree
25 and then representing a custom tree inside an .ebuild file by taking the
26 benchmark portage tree reference + one or more patch deltas. The
27 "distribution ebuild" file would really not be large, as it would contain
28 little more than tags, references, and patches, just as standard ebuild files
29 exist today for packages. Since cvs already manages repository size by
30 representing changes as deltas, I doubt a cvs explosion would be likely. The
31 real win with cvs (or other versioning tools) is the way in which tags can be
32 locked to constant snapshots of the tree which are invariant over the lifetime
33 of the repository. This constancy is important because it provides a solid
34 foundation against which patch deltas can be derived, and would therefore
35 allow a particular gentoo snapshot (as represented by a patch against a cvs
36 tag) to be accessible indefinitely, leveraging the versioning capability of
37 cvs to prevent explosions in size and complexity.
39 I really do believe that the holy grail of meta-distributions is to achieve
40 the representation of an entire distribution in a compact, textual form,
41 allowing the tools of open source development (diff, patch, cvs, etc.) to be
42 applied to the distribution tree itself, and allowing the distribution to
43 evolve along different lines of evolution, but having the tools to keep the
44 different versions in sync.
46 Take, for example, the linux kernel. A quick glance at shows a
47 whole bunch of kernels, 10 to be exact. Many of them are simply someone's
48 personal selection of patches, appended with their initials. But these 10
49 versions are not true forks, they are only alternative versions of the same
50 overall evolutionary progression. It's really the power of the versioning
51 tools, i.e. cvs, bitkeeper, etc. that gives us the ability to fork and then
52 remerge, making the forks ephemeral rather than irreconcilable, and preserving
53 an overall singularity of evolution even within an environment where multiple,
54 distributed repositories exist.
56 My idea is simply to take the _concept_ of cvs, bitkeeper, and distributed
57 versioning repositories as it is used in linux kernel development, and apply
58 it to making a true meta-distribution of gentoo. To the extent that the
59 portage tree concept is really a kind of source code for developing
60 distributions, and the fact that distributed development tools like diff,
61 patch, and cvs are already quite mature, I believe that it's not such a big
62 leap from concept to implementation.
64 James
67 --
68 gentoo-dev@g.o mailing list