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. |