Hello, its a nice proposal, but one that shows our current systems
weakness right now.

Fex. we currently have 256 package entries in package.mask
$(cat package.mask |grep "/" - |grep -v "#" - |wc -l)
    256
How many of those are known "BROKEN" packages and how many are just
there because we need more testing, or because some older package needs
a checkup to make sure it all works nicely?

Anyone? can you answer without looking into the package.mask?
I know I cant.. I also know I have some packages there that just need
some more user input before we can unmask them and call them stable.

To split package.mask into "broken.mask" and "testme.mask" could solve
part of this, simply autogenerating package.mask at every emerge is a
trivial task for that matter. (cat broken.mask testme.mask>package.mask)

this isn't the magic solution we all have been waiting for.. sorry. I
dont think there is one here.


//Spider



begin  quote
On Thu, 18 Apr 2002 21:05:53 -0400
William McArthur <sandymac@gentoo.org> wrote:

> The following is some thoughts on how to provide the stability that I 
> think most users really want while keeping the bleeding edge ones
> happy. This was promped by the IRC discussion I posted to the list
> earlier today.
> 
> The problem with a stability metric on each pacakge as described in
> the channel is it doesn't describe the stability of the interaction of
> the packages between each other. It would not have solved the libpng 
> problems many users had. Becuase I'm sure libpng-1.2.* is a solid 
> package and each other package that linked against libpng-1.0.* would 
> have had a reasonable stability metric from it's use before 
> libpng-1.2.* was released.
> 
> What I think would work well is a checkpoint system where every other 
> month or so we have a package freeze for about a week or less. Then
> what I call a update.mask is generated based on the newest versions of
> all working packages out there. I originally thought of checkpoints as
> milestones like the mozilla guys use but a milestone is a goal, this
> is more like a saved state in a game.
> 
> This update.mask is a lot like the package.mask in format but instead
> of disabling packages it defines a leading edge of packages that are
> not `emerge --update world` past. Kinda like drawing a line in the
> sand and saying all packages on one side of the line are reasonably
> tested to work well together. If the user wants to he can explictly
> emerge a package that is on the other side of that line but it would
> require him to type the version he wants.
> 
> Also, I think this would obsolete the "world favorites" list that is 
> maintained for a system. As I understand this feature it is to prevent
> the endless recompiling of point release of dependicies.
> 
> I envision an option added to emerge that is like the `java-config 
> --list-available-vms` but it would be `emerge 
> --list-available-checkpoints`. The user can then select the desired 
> checkpoint with something like `emerge --set-checkpoint
> gentoo-YYYY-MM` which then updated a symlink or something to the
> selected update.mask file. Also it would be nice to have a bleeding
> edge update.mask that doens't draw any leading edge.
> 
> One thing I haven't figured out is how to deal with new packages added
> after the update.mask. The update.mask wouldn't know about the new 
> package and I think updating old check points should be advoided. 
> Suggestions welcome.
> 
> Feed back welcomed.
> 
> Sandy McArthur
> 
> 
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev


--
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end