On Fri, 16 Oct 2009 23:29:00 -0000 (UTC)
"Daniel Bradshaw" <daniel@...> wrote:

> Hi all,
> 
> It occurs to me that my work flow when doing updates follows a fairly
> predictable (and probably common) pattern.
> The obvious next step is to wonder why no one though of automating it...
> 
> When doing updates I tend to look through the package list and classify
> things based on how likely they are to break.
> Some packages, like findutils, are pretty robust and generally just get on
> with working.
> Other packages, like apache and ssh, need are more fragile and need plenty
> of configuration.
> 
> Packages from the second group want emerging on their own, or in small
> groups, the better to keep an eye out for notices about things that might
> break, to update configs, and to check that they're running happily.
> 
> Once the update list is reduced to packages from the first group it's
> fairly safe to run emerge -u world and not worry about things exploding
> too badly.
> 
> 
> So as I say, it occurs to me that most people probably follow some
> variation of this selective upgrade method.
> It might be handy to have some kind of metadata in the ebuilds that can be
> used to indicate a package that is "demanding".
> Then that flag could be used to highlight the package on a dep tree, or
> optionally to block the emerge unless the package is specified explicitly.
> 
> `emerge -vaut @safe` would be kinda useful.
> 
> Just a thought.

As Jeremy said this is really subjective.  I think what might be a more
reasonable thing to ask for is a way to mark particular upgrades as
potentially troublesome.  Personally I just alias e='emerge -avl' and pay
attention to the changelogs.


-- 
fonts,                             Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662