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

[Michael Cummings]

Not to be a nay sayer, because I like the idea of a stable tree, but one hitch is that in our current setup, we pull source from the source, but sometimes those source packages go away - hence the new ebuild. Not a universal, just pointing it out (happens in dev-perl/* for instance). Just sharing,

Mike

On Sat, 28 Jun 2003 22:59:52 -0000
"James Yonan" <jim@×××××.net> wrote:

> Martin Schlemmer <azarah@g.o> 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@g.o mailing list


-- 

-----o()o---------------------------------------------
              |  #gentoo-dev  on irc.freenode.net
Gentoo Dev    |  #gentoo-perl on irc.freenode.net
Perl Guy      |
              |  GnuPG Key ID:       AB5CED4E9E7F4E2E
-----o()o---------------------------------------------