Re: [gentoo-dev] The problem of stable/current. Was: Re: [gentoo-dev] the vision for Gentoo

["James Yonan" <jim@yonan.net>]

Martin Schlemmer <azarah@gentoo.org> 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