Gentoo Archives: gentoo-dev

From: William McArthur <sandymac@g.o>
To: Gentoo Dev <gentoo-dev@g.o>
Subject: [gentoo-dev] Improving stability - checkpoints
Date: Fri, 19 Apr 2002 21:16:01
Message-Id: 3CC0CF44.8050303@gentoo.org
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

Replies

Subject Author
Re: [gentoo-dev] Improving stability - checkpoints Bill Kenworthy <billk@×××××××××.au>