Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]

[Rich Freeman]

On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard <kumba@g.o> wrote:
> And thus, I was referring only to @system, not a stage3.  I think an editor
> should be in @system, but as much as I like nano, I know the ncurses
> dependency won't sit well with everyone.  If @system is supposed to be a
> minimal-working system, a minimal vim deserves consideration.  But if
> ncurses is already being dragged in by something else, then stick with nano.
>

That's the thing.  I don't think that @system should be a
"minimal-working system."  That has been the past attitude towards it,
and it causes issues.


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

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.

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.

--
Rich