1 |
[Sorry if this is a duplicate, I'm currently demonstrating a severe lack |
2 |
of email skills.] |
3 |
|
4 |
The other day there was a discussion on IRC about improving the |
5 |
stability of the distro as a whole. The popular idea at the time was a |
6 |
stability metric applied to each package based on a few things. The |
7 |
following is my thoughts on how to improve the situation with minimal |
8 |
developer effort. |
9 |
|
10 |
First, I don't think the stability metric idea won't have it's desired |
11 |
effect. The libpng problems would not be prevented with a stability |
12 |
metric. The problem was not with the package specificlly but the |
13 |
interaction between pacakges. Specifically packages that linked with |
14 |
libpng and expected libpng-1.0.* . |
15 |
|
16 |
We need something to describe a stable system as a whole. There are |
17 |
other sumissions out there but I'm unconvinced that they would improve |
18 |
stability. |
19 |
|
20 |
I propose something I've dubbed a checkpoint as a feature to be added to |
21 |
emerge and a step in our developement process. Every other month or so |
22 |
we have a package freeze where we create a new checkpoint. Checkpoint |
23 |
file(s) describe the reasonably stable leading edge of each package |
24 |
currently available. Then during this freeze we test pacakges, the |
25 |
interaction between packages and the upgrade process. |
26 |
|
27 |
Checkpoints are not like the package.mask because they don't exclude |
28 |
packages and don't prevent the user from upgrading package past what is |
29 |
listed in the checkpoint file. They describe the newest packages that |
30 |
`emerge foo` or `emerge --update world` will upgrade to. The user is |
31 |
still free to specify a newer version manually if for some reason they |
32 |
want to. Think of them as a line in the sand where everything on one |
33 |
side is considered reasonably stable and tested. |
34 |
|
35 |
I envision a tool, it could be part of emerge, that is like the |
36 |
java-config's --list-available-vms and --set-system-vm= arguments. The |
37 |
tool handles the selection of the current checkpoint file. For example: |
38 |
============ |
39 |
$ emerge --list-checkpoints |
40 |
x86-bleeding-edge |
41 |
x86-curent-stable |
42 |
x86-2002-apr |
43 |
x86-2002-feb |
44 |
Checkpoint is currently set to: x86-2002-feb |
45 |
$ emerge --set-checkpoint=x86-2002-apr |
46 |
Checkpoint is now set to: x86-2002-apr |
47 |
============ |
48 |
|
49 |
The bleeding-edge and current-stable checkpoints are special. |
50 |
Bleeding-edge is effictivly no checkpoint at all, or always the newest |
51 |
packages. Current-stable is like a sym-link to the most recent |
52 |
checkpoint and is automatically updated when a new checkpoint is final. |
53 |
In the above example that would be x86-2002-apr. |
54 |
|
55 |
Checkpoint files should not be changed once deemed final. Thus they |
56 |
should be written so to allow a little wiggle room for bugfixes, |
57 |
probably only within different releases of the same ebuild version. |
58 |
|
59 |
This makes good use of a developers time beacuse they aren't chasing |
60 |
bugs due to all the variations of various pacages they didn't test. |
61 |
|
62 |
Many users will like not having to compile every point release of a |
63 |
package that is needed by some package they are merging. This is a |
64 |
duplicate benefit of the world favorits and I think obsletes it. |
65 |
|
66 |
Many more users will like the reduced risk of 'emerge --update world' |
67 |
leaving their system in a b0rken state. Users that want the bleeding |
68 |
edge can still have it by specifing a package version or the bleeding |
69 |
edge checkpoint file. |
70 |
|
71 |
Checkpoints would only be considered supported until they are two or |
72 |
three checkpoints old. |
73 |
|
74 |
I hope this makes sense. I'm having trouble keeping my thoughts straight |
75 |
and this is the second time I've written this due to a system crash. |
76 |
|
77 |
As always, feed back is desired. |
78 |
|
79 |
Sandy McArthur |