1 |
Chris Gianelloni wrote: |
2 |
|
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. |
36 |
|
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. |
40 |
|
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. |
44 |
|
45 |
Perhaps more people could respond so we can see how everyone feels (I |
46 |
want this route.) |
47 |
|
48 |
Tux |
49 |
|
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 |