[gentoo-dev] System stability - update.mask

[gentoo-dev] System stability - update.mask

[William McArthur]

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

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

[Terje Kvernes]

William McArthur <sandymac@gentoo.org> 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

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

[Spider]

[-- Attachment #1: Type: text/plain, Size: 3815 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]