| 1 |
On Sunday, September 07, 2014 05:57:57 PM Joshua Kinard wrote: |
| 2 |
> On 09/07/2014 17:04, Rich Freeman wrote: |
| 3 |
> > On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard <kumba@g.o> |
| 4 |
wrote: |
| 5 |
|
| 6 |
<snipped> |
| 7 |
|
| 8 |
> >> As for Parallel builds, do you make make -jX? Or running concurrent |
| 9 |
> >> emerges in different shells? I wasn't commenting at all on parallel |
| 10 |
> >> builds.> |
| 11 |
> > I was referring to --jobs. The issue with @system is that you can't |
| 12 |
> > build packages in @system in parallel, or their dependencies. Now, |
| 13 |
> > I'm not sure if that extends to dependencies of virtual packages - if |
| 14 |
> > not then an editor isn't as much of a problem. However, you're still |
| 15 |
> > stuck with lots of whining by portage if you unmerge your last editor. |
| 16 |
> > I think we really need to reserve that for situations where you're |
| 17 |
> > actually likely to break something. You can unmerge and re-merge an |
| 18 |
> > editor without any issues at all, and there are probably lots of |
| 19 |
> > useful substitutes for editors that aren't in the editor virtual. |
| 20 |
> |
| 21 |
> Well, I believe a stage2 in catalyst is just a remerge of @system, and |
| 22 |
> that's only ~12 hours on my Octane, which is perfectly fine for me. So |
| 23 |
the |
| 24 |
> parallelization isn't a real concern. Stage3 takes ~30hrs, though, so I'd |
| 25 |
> be curious to see if that parallelizes well once I get SMP working on that |
| 26 |
> machine. |
| 27 |
> |
| 28 |
> Then again, those of us who work with slower hardware probably have a |
| 29 |
much |
| 30 |
> higher level of patience than others. So while the inability to parallelize |
| 31 |
> the @system merge isn't a concern for me, it is for others. |
| 32 |
|
| 33 |
With faster hardware, I don't need as much patience. |
| 34 |
But on slower machines, as I am used to fast ones, I tend to notice the |
| 35 |
lack of parallellism during the emerge-phase. |
| 36 |
|
| 37 |
> > I'm not suggesting that we rip out editor just now either. It makes |
| 38 |
> > more sense to just try to hold the line on @system until we have |
| 39 |
> > something better actually implemented (like mix-ins), and then it |
| 40 |
> > won't be a big deal if we trim it down further. |
| 41 |
> |
| 42 |
> The editor is a total non-issue to me. I simply raised it as part of my |
| 43 |
> reply to branch the thread off. I am perfectly fine keeping virtual/editor |
| 44 |
> in @system and letting nano be the primary satisfier. |
| 45 |
|
| 46 |
Personally, I would not have an issue with the stage3 not having an editor, |
| 47 |
but it would make installing Gentoo more difficult considering there are |
| 48 |
some files that need to be edited. And the handbook actually references |
| 49 |
"nano". |
| 50 |
|
| 51 |
> > To cut down on replies - the reason nano is preferred is that it is |
| 52 |
> > the first package in the virtual, which is the usual rule. Of course, |
| 53 |
> > it was placed there deliberately since it is a simple editor with few |
| 54 |
> > dependencies and both the vi and emacs camps can agree that it is |
| 55 |
> > lousy. |
| 56 |
> |
| 57 |
> The vi and emacs camps agreeing on something? Impossible! |
| 58 |
|
| 59 |
I think both camps do the following: |
| 60 |
emerge <preferred editor> |
| 61 |
emerge -C nano |
| 62 |
as one of the first steps. |
| 63 |
|
| 64 |
The first thing I do on a new install as soon as a portage tree is available is |
| 65 |
run the above. |
| 66 |
|
| 67 |
-- |
| 68 |
Joost |
Archives