1 |
Martin Schlemmer <azarah@g.o> said: |
2 |
|
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. |
23 |
|
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. |
38 |
|
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. |
45 |
|
46 |
Take, for example, the linux kernel. A quick glance at kernel.org 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. |
55 |
|
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. |
63 |
|
64 |
James |
65 |
|
66 |
|
67 |
-- |
68 |
gentoo-dev@g.o mailing list |