From: Michael Cummings <mcummings@gentoo.org>
To: "James Yonan" <jim@yonan.net>
Cc: "Gentoo-Dev" <gentoo-dev@gentoo.org>
Subject: Re: [gentoo-dev] The problem of stable/current. Was: Re: [gentoo-dev] the vision for Gentoo
Date: Sun, 29 Jun 2003 07:13:22 -0400 [thread overview]
Message-ID: <20030629071322.4284d463.mcummings@gentoo.org> (raw)
In-Reply-To: <twig.1056841191.52006@yonan.net>
[-- Attachment #1: Type: text/plain, Size: 4412 bytes --]
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@yonan.net> wrote:
> 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
--
-----o()o---------------------------------------------
| #gentoo-dev on irc.freenode.net
Gentoo Dev | #gentoo-perl on irc.freenode.net
Perl Guy |
| GnuPG Key ID: AB5CED4E9E7F4E2E
-----o()o---------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-06-29 11:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-28 9:18 [gentoo-dev] the vision for Gentoo Daniel Robbins
2003-06-28 14:17 ` gerrynjr
2003-06-28 15:35 ` [gentoo-dev] private mailing lists? (was [Re: [gentoo-dev] the vision for Gentoo]) Todd Berman
2003-06-28 17:24 ` [gentoo-dev] the vision for Gentoo Michael Kohl
2003-06-28 21:31 ` [gentoo-dev] The problem of stable/current. Was: " James Yonan
2003-06-28 21:49 ` Martin Schlemmer
2003-06-28 22:59 ` James Yonan
2003-06-29 10:03 ` Martin Schlemmer
2003-06-29 11:13 ` Michael Cummings [this message]
2003-06-29 0:52 ` Jens Hoffrichter
2003-06-28 22:01 ` Svyatogor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030629071322.4284d463.mcummings@gentoo.org \
--to=mcummings@gentoo.org \
--cc=gentoo-dev@gentoo.org \
--cc=jim@yonan.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox