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