1 |
Hello, its a nice proposal, but one that shows our current systems |
2 |
weakness right now. |
3 |
|
4 |
Fex. we currently have 256 package entries in package.mask |
5 |
$(cat package.mask |grep "/" - |grep -v "#" - |wc -l) |
6 |
256 |
7 |
How many of those are known "BROKEN" packages and how many are just |
8 |
there because we need more testing, or because some older package needs |
9 |
a checkup to make sure it all works nicely? |
10 |
|
11 |
Anyone? can you answer without looking into the package.mask? |
12 |
I know I cant.. I also know I have some packages there that just need |
13 |
some more user input before we can unmask them and call them stable. |
14 |
|
15 |
To split package.mask into "broken.mask" and "testme.mask" could solve |
16 |
part of this, simply autogenerating package.mask at every emerge is a |
17 |
trivial task for that matter. (cat broken.mask testme.mask>package.mask) |
18 |
|
19 |
this isn't the magic solution we all have been waiting for.. sorry. I |
20 |
dont think there is one here. |
21 |
|
22 |
|
23 |
//Spider |
24 |
|
25 |
|
26 |
|
27 |
begin quote |
28 |
On Thu, 18 Apr 2002 21:05:53 -0400 |
29 |
William McArthur <sandymac@g.o> wrote: |
30 |
|
31 |
> The following is some thoughts on how to provide the stability that I |
32 |
> think most users really want while keeping the bleeding edge ones |
33 |
> happy. This was promped by the IRC discussion I posted to the list |
34 |
> earlier today. |
35 |
> |
36 |
> The problem with a stability metric on each pacakge as described in |
37 |
> the channel is it doesn't describe the stability of the interaction of |
38 |
> the packages between each other. It would not have solved the libpng |
39 |
> problems many users had. Becuase I'm sure libpng-1.2.* is a solid |
40 |
> package and each other package that linked against libpng-1.0.* would |
41 |
> have had a reasonable stability metric from it's use before |
42 |
> libpng-1.2.* was released. |
43 |
> |
44 |
> What I think would work well is a checkpoint system where every other |
45 |
> month or so we have a package freeze for about a week or less. Then |
46 |
> what I call a update.mask is generated based on the newest versions of |
47 |
> all working packages out there. I originally thought of checkpoints as |
48 |
> milestones like the mozilla guys use but a milestone is a goal, this |
49 |
> is more like a saved state in a game. |
50 |
> |
51 |
> This update.mask is a lot like the package.mask in format but instead |
52 |
> of disabling packages it defines a leading edge of packages that are |
53 |
> not `emerge --update world` past. Kinda like drawing a line in the |
54 |
> sand and saying all packages on one side of the line are reasonably |
55 |
> tested to work well together. If the user wants to he can explictly |
56 |
> emerge a package that is on the other side of that line but it would |
57 |
> require him to type the version he wants. |
58 |
> |
59 |
> Also, I think this would obsolete the "world favorites" list that is |
60 |
> maintained for a system. As I understand this feature it is to prevent |
61 |
> the endless recompiling of point release of dependicies. |
62 |
> |
63 |
> I envision an option added to emerge that is like the `java-config |
64 |
> --list-available-vms` but it would be `emerge |
65 |
> --list-available-checkpoints`. The user can then select the desired |
66 |
> checkpoint with something like `emerge --set-checkpoint |
67 |
> gentoo-YYYY-MM` which then updated a symlink or something to the |
68 |
> selected update.mask file. Also it would be nice to have a bleeding |
69 |
> edge update.mask that doens't draw any leading edge. |
70 |
> |
71 |
> One thing I haven't figured out is how to deal with new packages added |
72 |
> after the update.mask. The update.mask wouldn't know about the new |
73 |
> package and I think updating old check points should be advoided. |
74 |
> Suggestions welcome. |
75 |
> |
76 |
> Feed back welcomed. |
77 |
> |
78 |
> Sandy McArthur |
79 |
> |
80 |
> |
81 |
> |
82 |
> _______________________________________________ |
83 |
> gentoo-dev mailing list |
84 |
> gentoo-dev@g.o |
85 |
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev |
86 |
|
87 |
|
88 |
-- |
89 |
begin .signature |
90 |
This is a .signature virus! Please copy me into your .signature! |
91 |
See Microsoft KB Article Q265230 for more information. |
92 |
end |