Re: [gentoo-dev] System stability - update.mask

[Terje Kvernes]

William McArthur <sandymac@g.o> writes:

> 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.

  dang, I missed that.  :/
 
> 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.

  not directly no, and that _might_ be a problem.

> 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.

  it _would_ solve that issue, because the author of the ebuild
  wouldn't (or at least shouldn't) label that package as stable before
  it has been around the block a while.  and even though you _only_
  need to deal with your own package, using a bit of common sense
  isn't a bad idea.  :)
 
> 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.

  hm, okay, that doesn't seem like a bad idea though.  what I don't
  like about this is that you get locked into a set of packages.  we
  should try to work against the stability of packages, not just say
  "these packages have known bugs, so they're stable".
 
> 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.

  oki.  not a bad idea.  *thinking*
 
  [ ... ]

> 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.

  it would be a must, and I certainly want to be able to say "set
  checkpoint <here> but still get me the newest mplayer".
 
> 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.

  sorry, no good ideas.  I've done some work on my end with the idea
  of having a single stable package of every ebuild, where you
  basically symlink something like

  "ln -s xgammon-0.98a xgammon-stable"
 
  and I'm currently adding support for this in emerge.  but it should
  be nested deeper in the system, but looking at the portage code has
  scared me a bit.  it's been a while since I did python as well.  :/

  support for developer update reasons is also on its way, but has the
  same general problem as above.

-- 
Terje