On Fri, 16 Oct 2009 23:29:00 -0000 (UTC) "Daniel Bradshaw" <[email protected]> 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
signature.asc
Description: PGP signature
