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