Gentoo Archives: gentoo-dev

From: Andrew Muraco <tuxp3@×××××××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Gentoo "Stable" Portage/Releases
Date: Sun, 08 Jan 2006 07:12:19
In Reply to: [gentoo-dev] Gentoo "Stable" Portage/Releases by Chris Gianelloni
1 Chris Gianelloni wrote:
3 >First off, let me just say that this was just an idea I'd cooked up a
4 >while back, so I am sure there's lots of holes in it for you guys to rip
5 >apart. Anyway, without further ado...
6 >
7 >The proposal is quite simple insofar as it requires no changes to
8 >portage, whatsoever (though there are possibilities to make extensions
9 >to portage). It introduces no new KEYWORDS and adds no load on the
10 >current ebuild developers, other than those that wish to work on the
11 >stable tree.
12 >
13 >Allow me to explain.
14 >
15 >First, there is the creation of the "release" tree. This tree is tied
16 >to a specific release of Gentoo Linux. The tree is based on the release
17 >snapshot used to build the release. The tree consists of the highest
18 >version stable ebuild per slot and architecture for each package. This
19 >means if there is no stable version of, say, vmware-player, then the
20 >entire package is omitted. For things like GTK+, there would be at
21 >least 2 versions in the tree, since there are 2 slots and both are
22 >stable on at least one architecture. By only limiting the tree in this
23 >manner, it can be built entirely by a script and require no manual
24 >interactions to repair dependencies, etc.
25 >
26 >So let's imagine that 2006.0 is rolling around. The 2006.0 snapshot is
27 >frozen, and the release-building begins. This snapshot tarball is run
28 >through our "stable" script, and a new gentoo-2006.0 CVS module is
29 >created. A corresponding rsync module is created for this tree.
30 >
31 >
32 >
33 I like this Idea alot actually, the only think I can see as a downside
34 is that the SYNC=".." could be changed accdentally, making it just
35 another Gentoo tree.
37 Another thing that I don't like, is the feel of this method does seem
38 "offical" enough.. mostly because portage is not 'stable'-aware, Its
39 just using a stripped down tree.
41 I think your idea is good, its just the details that need to be worked
42 out, (how long to keep the trees?)
43 My little piece on GLEP19 seems to have just been obsoleted.
45 Perhaps more people could respond so we can see how everyone feels (I
46 want this route.)
48 Tux
50 >To facilitate "enterprise" usage, we break up the releases into a
51 >"desktop" and "server" set. This means the current
52 >"default-linux/$arch/2006.0" profile would be
53 >"default-linux/$arch/2006.0/desktop" with a
54 >"default-linux/$arch/2006.0/server" profile, also. The stages would be
55 >built against the "default-linux/$arch/2006.0" profile, which would have
56 >any USE, etc. that are common between desktop and server. During
57 >installation, the user can choose to use either the desktop or server
58 >profiles, or stay with the more "generic" 2006.0 profile (good for
59 >developers, etc. that might need components of both, or want a more
60 >minimal default set of USE flags). The desktop and server profiles will
61 >have a defined set of default USE flags that will benefit the most
62 >people, similar to how the current profiles are designed to be "desktop"
63 >profiles, to benefit the most people.
64 >
65 >
66 --
67 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] Gentoo "Stable" Portage/Releases Andrew Muraco <tuxp3@×××××××××.com>
Re: [gentoo-dev] Gentoo "Stable" Portage/Releases Donnie Berkholz <spyderous@g.o>