On Fri, 20 Jan 2012 07:49:07 -0500 Rich Freeman <ri...@gentoo.org> wrote:
> On Thu, Jan 19, 2012 at 10:33 PM, Duncan <1i5t5.dun...@cox.net> wrote: > > Zac Medico posted on Thu, 19 Jan 2012 16:39:12 -0800 as excerpted: > > > >> Maybe it would be enough to add a suggestion about --exclude in the > >> --newuse section of the emerge man page? I don't think this is > >> confusing enough to qualify for an interactive suggestion. > > > > However, it could be argued that the various boilerplate > > "handholding" we're already doing has set the precedent. > > I think the manpage is the right place to fix it. Users would find > out about -N from the manpage or from following -dev. Fixing it in > that place seems appropriate. Right now I think experienced users are > more likely to be using it. > > I'd still like to see our handbook include a recommended workflow for > keeping gentoo up-to-date. Perhaps that should include a few options > with the pros/cons of each. I'd think that emerge -auDNv world would > be one of those options. Perhaps another might be including build > deps. One advantage of having people running a uniform update command > that tends to keep everything up to date (even if not strictly > necessary), is that it would cut down on the diversity of our install > base. Right now a stable user could be running various versions of > various libraries based on when they first merged them and whether > they use -D, and so on. Keeping everybody moving along to newer > versions (and more freshly compiled ones) could help to cut down on > the bugs. Bugs filed with older versions still in portage would still > be legitimate, but unless somebody really needs the older version > there is no sense making more work for ourselves. > > Perhaps this is worth its own thread, as this one is already drifting > way off topic. > > Rich > I'm sure there is already such a thread on *-dev and the only sane thing would be to introduce an option along the line of "emerge --update world" which condenses all best practice options into a single one and which can change over time together with the best practices. Though this doesn't change the fact that messing with stable ebuilds is dangerous and clearly labelled a "don't do" in the dev-manual even so it is sometimes unavoidable.
