1 |
On Friday 19 April 2002 03:19 am, Einar Karttunen wrote: |
2 |
> On 19.04 11:44, Terje Kvernes wrote: |
3 |
> > the only problem I see with using a profile is that it'll "lock" you |
4 |
> > down more than you'd like. it would be nice to say "give me a |
5 |
> > stable core, but a bleeding edge movieplayer and games". |
6 |
> |
7 |
> Which is where branches like in debian help you. There are some problems |
8 |
> however. A big one is dependencies e.g. packages A and B use package C, |
9 |
> and need a specific version. A and B of stable use C version 1.2 and |
10 |
> the ones in devel 2.0. Now you want to use the devel version of A on |
11 |
> your stable system and have to use the devel versions of A, B and C. |
12 |
> Replace C with e.g. gtk and you see the problem. |
13 |
|
14 |
Here's my suggestion posted previouly to the Gentoo-user list. I think this |
15 |
solution prevents the problems associated with branches, while not locking |
16 |
anyone into a system that they're not happy with. |
17 |
|
18 |
I propose the addition of stability levels to gentoo. This would allow users |
19 |
to run a bit behind the state-of-the-art, while still taking advantage of the |
20 |
features Portage provides. |
21 |
|
22 |
The levels I propose would be something like: |
23 |
Stable: Conservative, for people who require extreme stability. |
24 |
Standard: The base level. A few weeks behind what we have today. |
25 |
Current: Gentoo as we know it today. For people who are a bit more |
26 |
adventurous, but aren't willing to accept betas. |
27 |
Devel: beta packages are installed by default. Only for the most adventurous. |
28 |
|
29 |
In addition, all packages at a fixed version level (ie 1.0) would be flagged |
30 |
as such, allowing a user to recreate that version number months down the |
31 |
road. |
32 |
|
33 |
This doesn't lock people in to a given stability level, it only changes the |
34 |
default behavior of the installer & emerge. The stability level could always |
35 |
be overridden, just by specifying a newer (or older) version of a particular |
36 |
package. |
37 |
|
38 |
These features should be easy to implement on top of the current package mask |
39 |
system (though I should state: I am not a programmer, and am not very |
40 |
familiar with the internal workings of Portage). |
41 |
|
42 |
This should not be viewed as creating 'branches'. Instead, it creates |
43 |
'reference points'. All development takes place at the devel level. From |
44 |
there, the only maintenance required would be gradually changing the masks to |
45 |
move packages in to the progressively more stable environments. This will |
46 |
require some extra work on behalf of the package maintainers, but it |
47 |
shouldn't require more then maybe 30 minutes of work a month on actively |
48 |
developed packages (even less on the vast majority of packages). |
49 |
|
50 |
A more flexible package management system simplifies things greatly. Many |
51 |
users don't want a bleeding edge system. How often are significant bugs |
52 |
discovered only after a upgrade has been available for weeks? And in the |
53 |
three months or so I've been using Gentoo, I've already seen at least a |
54 |
couple of times when packages were accidentally unmasked prematurely. |
55 |
|
56 |
Having stability levels allow the adventurous to run a bleeding edge system, |
57 |
the middle 80% can run a system that is maybe a few weeks behind the bleeding |
58 |
edge. And those people who need a bit more stability can run stable. |
59 |
|
60 |
Gentoo's ease of management makes it ideal in many ways for an office |
61 |
environment and servers, but when you have users relying on the computers |
62 |
working every morning when they get there, bleeding edge doesn't cut it. |
63 |
Having a stable flag makes this sort of system manageable. |