Chris Gianelloni wrote:
First off, let me just say that this was just an idea I'd cooked up a
while back, so I am sure there's lots of holes in it for you guys to rip
apart. Anyway, without further ado...
The proposal is quite simple insofar as it requires no changes to
portage, whatsoever (though there are possibilities to make extensions
to portage). It introduces no new KEYWORDS and adds no load on the
current ebuild developers, other than those that wish to work on the
stable tree.
Allow me to explain.
First, there is the creation of the "release" tree. This tree is tied
to a specific release of Gentoo Linux. The tree is based on the release
snapshot used to build the release. The tree consists of the highest
version stable ebuild per slot and architecture for each package. This
means if there is no stable version of, say, vmware-player, then the
entire package is omitted. For things like GTK+, there would be at
least 2 versions in the tree, since there are 2 slots and both are
stable on at least one architecture. By only limiting the tree in this
manner, it can be built entirely by a script and require no manual
interactions to repair dependencies, etc.
So let's imagine that 2006.0 is rolling around. The 2006.0 snapshot is
frozen, and the release-building begins. This snapshot tarball is run
through our "stable" script, and a new gentoo-2006.0 CVS module is
created. A corresponding rsync module is created for this tree.
I like this Idea alot actually, the only think I can see as a downside
is that the SYNC=".." could be changed accdentally, making it just
another Gentoo tree.
Another thing that I don't like, is the feel of this method does seem
"offical" enough.. mostly because portage is not 'stable'-aware, Its
just using a stripped down tree.
I think your idea is good, its just the details that need to be worked
out, (how long to keep the trees?)
My little piece on GLEP19 seems to have just been obsoleted.
Perhaps more people could respond so we can see how everyone feels (I
want this route.)
Tux
To facilitate "enterprise" usage, we break up the releases into a
"desktop" and "server" set. This means the current
"default-linux/$arch/2006.0" profile would be
"default-linux/$arch/2006.0/desktop" with a
"default-linux/$arch/2006.0/server" profile, also. The stages would be
built against the "default-linux/$arch/2006.0" profile, which would have
any USE, etc. that are common between desktop and server. During
installation, the user can choose to use either the desktop or server
profiles, or stay with the more "generic" 2006.0 profile (good for
developers, etc. that might need components of both, or want a more
minimal default set of USE flags). The desktop and server profiles will
have a defined set of default USE flags that will benefit the most
people, similar to how the current profiles are designed to be "desktop"
profiles, to benefit the most people.
--
[email protected] mailing list
