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

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

All,

there is a bug open requesting that we add sys-apps/iproute2 to the
system set [1]. Originally the request was to drop net-tools, but it has
become just adding iproute2.

If no one objects, I would like to do this sometime in the next 72
hours by adding sys-apps/iproute2 to profiles/default/linux/packages.

Thoughts?

William

[1] https://bugs.gentoo.org/189149

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Alex Xu]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

On 05/09/14 01:34 PM, William Hubbs wrote:
> All,
> 
> there is a bug open requesting that we add sys-apps/iproute2 to the
> system set [1]. Originally the request was to drop net-tools, but it has
> become just adding iproute2.
> 
> If no one objects, I would like to do this sometime in the next 72
> hours by adding sys-apps/iproute2 to profiles/default/linux/packages.
> 
> Thoughts?
> 
> William
> 
> [1] https://bugs.gentoo.org/189149
> 

no, because it's not necessary to bring up a working system. we don't
have wpa_supplicant, and we shouldn't have net-tools now that openrc
isn't in @system anymore.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Mike Gilbert]

On Fri, Sep 5, 2014 at 2:35 PM, Alex Xu <alex_y_xu@yahoo.ca> wrote:
> On 05/09/14 01:34 PM, William Hubbs wrote:
>> All,
>>
>> there is a bug open requesting that we add sys-apps/iproute2 to the
>> system set [1]. Originally the request was to drop net-tools, but it has
>> become just adding iproute2.
>>
>> If no one objects, I would like to do this sometime in the next 72
>> hours by adding sys-apps/iproute2 to profiles/default/linux/packages.
>>
>> Thoughts?
>>
>> William
>>
>> [1] https://bugs.gentoo.org/189149
>>
>
> no, because it's not necessary to bring up a working system. we don't
> have wpa_supplicant, and we shouldn't have net-tools now that openrc
> isn't in @system anymore.
>

Err... openrc is in profiles/base/packages. However, that really has
very little to do with this issue. I'm using systemd and still have
use for network config tools.

I would like to see iproute2 added to @system.

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

[Wyatt Epp]

On Fri, Sep 5, 2014 at 2:35 PM, Alex Xu <alex_y_xu@yahoo.ca> wrote:
>
> no, because it's not necessary to bring up a working system. we don't
> have wpa_supplicant, and we shouldn't have net-tools now that openrc
> isn't in @system anymore.
>
Well, your definition of "working" seems quite a bit narrower than mine!

More saliently, I recall having needed to do network-related things
from within my stage 3 chroot before, and I'd very much like that to
continue being possible.

-Wyatt

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

[Jauhien Piatlicki]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

05.09.14 21:21, Wyatt Epp написав(ла):
> On Fri, Sep 5, 2014 at 2:35 PM, Alex Xu <alex_y_xu@yahoo.ca> wrote:
>>
>> no, because it's not necessary to bring up a working system. we don't
>> have wpa_supplicant, and we shouldn't have net-tools now that openrc
>> isn't in @system anymore.
>>
> Well, your definition of "working" seems quite a bit narrower than mine!
> 
> More saliently, I recall having needed to do network-related things
> from within my stage 3 chroot before, and I'd very much like that to
> continue being possible.
> 

sys-apps/iproute2 is not necessary for this. stage3 already has enough stuff to work with network. Or am I wrong?

--
Jauhien



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

Dnia 2014-09-05, o godz. 12:34:11
William Hubbs <williamh@gentoo.org> napisał(a):

> there is a bug open requesting that we add sys-apps/iproute2 to the
> system set [1]. Originally the request was to drop net-tools, but it has
> become just adding iproute2.
> 
> If no one objects, I would like to do this sometime in the next 72
> hours by adding sys-apps/iproute2 to profiles/default/linux/packages.
> 
> Thoughts?

I object. We should be keeping towards making @system as small
as possible, not adding random packages there just because someone
happens to use them often.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Anthony G. Basile]

On 09/05/14 16:08, Michał Górny wrote:
> Dnia 2014-09-05, o godz. 12:34:11
> William Hubbs <williamh@gentoo.org> napisał(a):
>
>> there is a bug open requesting that we add sys-apps/iproute2 to the
>> system set [1]. Originally the request was to drop net-tools, but it has
>> become just adding iproute2.
>>
>> If no one objects, I would like to do this sometime in the next 72
>> hours by adding sys-apps/iproute2 to profiles/default/linux/packages.
>>
>> Thoughts?
> I object. We should be keeping towards making @system as small
> as possible, not adding random packages there just because someone
> happens to use them often.
>

I don't like to say no when people want something, but I think here I'm 
with Michal.  My idea of @system is that it must be the bare minimum to 
have a "working" system.  And for a working system you need just enough 
toolchain, networking and python to be able to bootstrap into whatever 
you want to build from that point.  We already have net-tools, so 
iproute2 is not needed.

Why can't you just emerge iproute2 from the stages we already have?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Mike Gilbert]

On Fri, Sep 5, 2014 at 4:30 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> On 09/05/14 16:08, Michał Górny wrote:
>>
>> Dnia 2014-09-05, o godz. 12:34:11
>> William Hubbs <williamh@gentoo.org> napisał(a):
>>
>>> there is a bug open requesting that we add sys-apps/iproute2 to the
>>> system set [1]. Originally the request was to drop net-tools, but it has
>>> become just adding iproute2.
>>>
>>> If no one objects, I would like to do this sometime in the next 72
>>> hours by adding sys-apps/iproute2 to profiles/default/linux/packages.
>>>
>>> Thoughts?
>>
>> I object. We should be keeping towards making @system as small
>> as possible, not adding random packages there just because someone
>> happens to use them often.
>>
>
> I don't like to say no when people want something, but I think here I'm with
> Michal.  My idea of @system is that it must be the bare minimum to have a
> "working" system.  And for a working system you need just enough toolchain,
> networking and python to be able to bootstrap into whatever you want to
> build from that point.  We already have net-tools, so iproute2 is not
> needed.
>
> Why can't you just emerge iproute2 from the stages we already have?
>

You can, and I do... every time I unpack a stage3 tarball.

Keeping @system minimal seems like a reasonable ideal though.

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

[Dirkjan Ochtman]

On Fri, Sep 5, 2014 at 10:30 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> I don't like to say no when people want something, but I think here I'm with
> Michal.  My idea of @system is that it must be the bare minimum to have a
> "working" system.  And for a working system you need just enough toolchain,
> networking and python to be able to bootstrap into whatever you want to
> build from that point.  We already have net-tools, so iproute2 is not
> needed.

+1 from me.

Cheers,

Dirkjan

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

Dnia 2014-09-05, o godz. 16:30:43
"Anthony G. Basile" <blueness@gentoo.org> napisał(a):

> On 09/05/14 16:08, Michał Górny wrote:
> > Dnia 2014-09-05, o godz. 12:34:11
> > William Hubbs <williamh@gentoo.org> napisał(a):
> >
> >> there is a bug open requesting that we add sys-apps/iproute2 to the
> >> system set [1]. Originally the request was to drop net-tools, but it has
> >> become just adding iproute2.
> >>
> >> If no one objects, I would like to do this sometime in the next 72
> >> hours by adding sys-apps/iproute2 to profiles/default/linux/packages.
> >>
> >> Thoughts?
> > I object. We should be keeping towards making @system as small
> > as possible, not adding random packages there just because someone
> > happens to use them often.
> >
> 
> I don't like to say no when people want something, but I think here I'm 
> with Michal.  My idea of @system is that it must be the bare minimum to 
> have a "working" system.  And for a working system you need just enough 
> toolchain, networking and python to be able to bootstrap into whatever 
> you want to build from that point.  We already have net-tools, so 
> iproute2 is not needed.

Even better, @system is basically stuff you don't want to depend
explicitly on or on which it is hard to depend on. As I see it, it
should be just the most basic stuff, like baselayout, shell, some basic
POSIX-defined utilities, some random stuff that PMS enforces, a C & C++
compiler.

As I see it, @system is already overburdened with random packages that
don't belong there. If we really feel like having to have something
else installed by default, why not just put it in default @world?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Anthony G. Basile]

On 09/05/14 17:20, Michał Górny wrote:
> Dnia 2014-09-05, o godz. 16:30:43
> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
>
>> On 09/05/14 16:08, Michał Górny wrote:
>>> Dnia 2014-09-05, o godz. 12:34:11
>>> William Hubbs <williamh@gentoo.org> napisał(a):
>>>
>>>> there is a bug open requesting that we add sys-apps/iproute2 to the
>>>> system set [1]. Originally the request was to drop net-tools, but it has
>>>> become just adding iproute2.
>>>>
>>>> If no one objects, I would like to do this sometime in the next 72
>>>> hours by adding sys-apps/iproute2 to profiles/default/linux/packages.
>>>>
>>>> Thoughts?
>>> I object. We should be keeping towards making @system as small
>>> as possible, not adding random packages there just because someone
>>> happens to use them often.
>>>
>> I don't like to say no when people want something, but I think here I'm
>> with Michal.  My idea of @system is that it must be the bare minimum to
>> have a "working" system.  And for a working system you need just enough
>> toolchain, networking and python to be able to bootstrap into whatever
>> you want to build from that point.  We already have net-tools, so
>> iproute2 is not needed.
> Even better, @system is basically stuff you don't want to depend
> explicitly on or on which it is hard to depend on. As I see it, it
> should be just the most basic stuff, like baselayout, shell, some basic
> POSIX-defined utilities, some random stuff that PMS enforces, a C & C++
> compiler.
>
> As I see it, @system is already overburdened with random packages that
> don't belong there. If we really feel like having to have something
> else installed by default, why not just put it in default @world?
>
I also don't want to see the stage3 tarballs bloated.  So I don't want 
to see net-tools and iproute2 ending up in our stage3's.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Rich Freeman]

On Fri, Sep 5, 2014 at 5:20 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Even better, @system is basically stuff you don't want to depend
> explicitly on or on which it is hard to depend on. As I see it, it
> should be just the most basic stuff, like baselayout, shell, some basic
> POSIX-defined utilities, some random stuff that PMS enforces, a C & C++
> compiler.
>
> As I see it, @system is already overburdened with random packages that
> don't belong there. If we really feel like having to have something
> else installed by default, why not just put it in default @world?
>

++

The purpose of the system set is to deal with circular deps and the
need to bootstrap.  We shouldn't have stuff in there if it is possible
to run without it.

There are loads of things I can't live without which aren't in the
system set.  I have a default world file that I always start with
anytime I do an install.  If we ever get mix-ins worked out that would
be another way to just have convenience sets of recommended software.

--
Rich

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

[Duncan]

Rich Freeman posted on Fri, 05 Sep 2014 20:10:02 -0400 as excerpted:

> The purpose of the system set is to deal with circular deps and the need
> to bootstrap.  We shouldn't have stuff in there if it is possible to run
> without it.
> 
> There are loads of things I can't live without which aren't in the
> system set.  I have a default world file that I always start with
> anytime I do an install.

Does portage still force serial builds of anything in the system-set and 
all deps thereof?[1]  If so, given a situation where even most phones are 
multi-core these days, does /anything/ other than circular deps and 
bootstrapping really justify forcing /all/ the several @system packages 
and deps I had before I started pruning, into serial build?

And isn't it time to think about something similar to the "-*" for USE 
flags, but aimed at @system instead, so those like me that wish to be 
free of the problem can simply set -* in /etc/portage/profile/packages 
and be done with it, instead of having to negate them one by one, and 
constantly patrol[2] lest a proposal such as this add something else to 
be negated?

I've been running @system-less for quite some time now, two years or 
better I think, and it hasn't killed my system yet.  While @system might 
be useful for bringing up a system as well as for the extra warnings on 
@system-set member removal it gives people who need a bit of hand-
holding, I think it's fair to say that I've demonstrated by now that it's 
entirely unnecessary on a system with a reasonably careful sysadmin 
(careful enough that if something bad /does/ happen, there's several 
levels of tested-bootable backup available that can be used to rescue the 
normal working-boot copy).

And/or, perhaps kill that forced @system serial emerge thing and let 
existing deps take care of things, if it hasn't been done already.  At 
least on amd64/nomultilib, it's obviously not necessary or I'd have run 
into issues by now.


[1] I wouldn't know, as that's one reason I decided to negate the entire 
system-set and now have an empty @system.

[2] For me, it's when I see emerge --pretend --depclean's empty-system-
set warning disappear.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Duncan]

Duncan posted on Sat, 06 Sep 2014 06:44:21 +0000 as excerpted:

> several @system packages and deps I had before I started pruning

Oops.  Several /hundred/ @system packages and deps... including kdelibs, 
due to USE=kde on some other dep.  IIRC, with only openrc in the @system 
set itself, there were still ~125 @system deps. =:^(

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Rich Freeman]

On Sat, Sep 6, 2014 at 2:44 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Rich Freeman posted on Fri, 05 Sep 2014 20:10:02 -0400 as excerpted:
>
>> The purpose of the system set is to deal with circular deps and the need
>> to bootstrap.  We shouldn't have stuff in there if it is possible to run
>> without it.
>>
>> There are loads of things I can't live without which aren't in the
>> system set.  I have a default world file that I always start with
>> anytime I do an install.
>
> Does portage still force serial builds of anything in the system-set and
> all deps thereof?[1]  If so, given a situation where even most phones are
> multi-core these days, does /anything/ other than circular deps and
> bootstrapping really justify forcing /all/ the several @system packages
> and deps I had before I started pruning, into serial build?

@system serves a couple of different purposes, and I think this is
part of the problem.

1.  One purpose of @system is simply convenience.  Devs don't want to
stick baselayout, bzip, sed, toolchain, etc in every other ebuild, so
it is basically a default dependency for everything.  This is what
makes parallel builds with @system and its deps unsafe - there is no
way for the package manager to know when there are dependency
relationships in the packages being built if we intentionally don't
specify them.  The only safe solution here is to minimize the size of
@system, either eliminating packages that aren't really such common
dependencies or suffer a bit more inconvenience.

The other purposes are all related to catalyst:

2.  Another purpose is to break the circular dependency problem when
building stage 1/2/3.  If you did ditch #1 entirely it would not be
straightforward to build a stage1/2/3 without some hints as to what
basically just needs to be pre-provided from the outside system as a
bootstrap.

3.  Yet another of its purposes is to determine what goes into the
stage3.  I'm actually wondering if something like a default world set
might be a better approach to that, or maybe we need a stage3 set or
something.  This is where packages like openssh fit in. or even man
and editor.

The thing is that #2-3 really only pertain to generating stage3s, and
that really only matters for the initial install.  After that,
everybody lives with it for the rest of their Gentoo lives.

Now that we actually have sets in portage, maybe it would make sense
to split up @system into different sets for each of those purposes.
Then we can optimize both the stage3 generation and the requirements
for installed systems separately.

--
Rich

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

[Anthony G. Basile]

On 09/06/14 07:05, Rich Freeman wrote:
> On Sat, Sep 6, 2014 at 2:44 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>> Rich Freeman posted on Fri, 05 Sep 2014 20:10:02 -0400 as excerpted:
>>
>>> The purpose of the system set is to deal with circular deps and the need
>>> to bootstrap.  We shouldn't have stuff in there if it is possible to run
>>> without it.
>>>
>>> There are loads of things I can't live without which aren't in the
>>> system set.  I have a default world file that I always start with
>>> anytime I do an install.
>> Does portage still force serial builds of anything in the system-set and
>> all deps thereof?[1]  If so, given a situation where even most phones are
>> multi-core these days, does /anything/ other than circular deps and
>> bootstrapping really justify forcing /all/ the several @system packages
>> and deps I had before I started pruning, into serial build?
> @system serves a couple of different purposes, and I think this is
> part of the problem.
>
> 1.  One purpose of @system is simply convenience.  Devs don't want to
> stick baselayout, bzip, sed, toolchain, etc in every other ebuild, so
> it is basically a default dependency for everything.  This is what
> makes parallel builds with @system and its deps unsafe - there is no
> way for the package manager to know when there are dependency
> relationships in the packages being built if we intentionally don't
> specify them.  The only safe solution here is to minimize the size of
> @system, either eliminating packages that aren't really such common
> dependencies or suffer a bit more inconvenience.
>
> The other purposes are all related to catalyst:
>
> 2.  Another purpose is to break the circular dependency problem when
> building stage 1/2/3.  If you did ditch #1 entirely it would not be
> straightforward to build a stage1/2/3 without some hints as to what
> basically just needs to be pre-provided from the outside system as a
> bootstrap.
>
> 3.  Yet another of its purposes is to determine what goes into the
> stage3.  I'm actually wondering if something like a default world set
> might be a better approach to that, or maybe we need a stage3 set or
> something.  This is where packages like openssh fit in. or even man
> and editor.

All true, but returning to the original point, even if packages in 
stage3 were a superset of @system, I would still argue against including 
iproute2 because of bloat for the reasons already stated. Don't get me 
wrong, I really like iproute2, but net-tools is sufficient for a 
stage3.  I like the idea that stage3 is pretty much defined by your 
points 1 and 2, with the implicit assumption of "a minimal set of 
packages be able to build any gentoo system" from it.  This minimal set 
idea is important because of its role in building stages via catalyst 
... see below.

>
> The thing is that #2-3 really only pertain to generating stage3s, and
> that really only matters for the initial install.  After that,
> everybody lives with it for the rest of their Gentoo lives.

If we fell like bikeshedding (and I'm up for a good discussion on the 
matter :), we can return to the old "stage4 = stage3 + extras" 
discussion.  Not having a clear picture of what a stage4 should and 
should not have in it, I don't have any a priori objections to adding 
openssh, man, vi and iproute2.  However, there is one big difference I 
see between stage4 and any of the other stages.  A proper catalyst run 
should be:

     stage3 -> stage1 -> stage2 -> stage3 -> etc

It should NOT include a stage4.  A stage4 would just be a spinoff of a 
stage3, and not be part of the catalyst cycle.  You *could* use a stage4 
as a stage3 seed, but it should not be necessary.  We should NOT have 
catalyst runs looking like:

     stage4 -> stage1 -> stage2 -> stage3 -> stage4 ->  etc

This would unnecessarily increase cpu time, contribute to the total 
entropy of the universe and speed up its heat death.  All bad things.

>
> Now that we actually have sets in portage, maybe it would make sense
> to split up @system into different sets for each of those purposes.
> Then we can optimize both the stage3 generation and the requirements
> for installed systems separately.
>
> --
> Rich
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Patrick Lauer]

On Friday 05 September 2014 12:34:11 William Hubbs wrote:
> All,
> 
> there is a bug open requesting that we add sys-apps/iproute2 to the
> system set [1]. Originally the request was to drop net-tools, but it has
> become just adding iproute2.

I wouldn't mind either option - net-tools has been deprecated for a decade, 
but if we still ship it as default it will be used.

Some people seem to think that stage3 is bloated - last time I looked at it 
there was lots of really-not-needed stuff like two python interpreters. If you 
want to de-bloat work on that, the extra 150kB or whatever of iproute2 are so 
small that it's barely noticeable.

And by the same reasoning of "bloat" we should remove openssh ( and maybe even 
rsync ;) ) because it's not strictly needed - so maybe we want a "minimal" and 
a "useful" stage3 ?

Have fun,

Patrick

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

[Rich Freeman]

On Sat, Sep 6, 2014 at 8:41 AM, Patrick Lauer <patrick@gentoo.org> wrote:
>
> And by the same reasoning of "bloat" we should remove openssh ( and maybe even
> rsync ;) ) because it's not strictly needed - so maybe we want a "minimal" and
> a "useful" stage3 ?

I could care less what is in the stage3, which only affects the
content of a gentoo system for its first 5 minutes of existence.  I
care more about what is in the system set.  Right now they're forced
to be the same thing. bit there is no reason that this has to be so.

If the stage3 bundles a bunch of stuff that either goes away at the
first --depclean or is just part of the initial world and can be
trivially removed (and there are no issues with parallel builds), then
I don't have a huge problem with it, though I still think that openssh
in the stage3 is overkill.

Minimal vs useful is certainly a good distinction, but just as with
the whole server profile debate the definition of useful varies
considerably.  I think that what would make the most sense is to
implement mix-ins so that everybody and their uncle can maintain their
own personal idea of a useful layer, and then strip the stage3 down to
what you really need to bootstrap a system, and limit the system set
to the stuff we really don't want to stick in every *DEPEND (libc,
baselayout, etc).

Trying to get everybody to agree on what is "useful" just leads to
endless bikeshedding - better to just let everybody or every project
have their own way and let everybody decide which way works for them.

--
Rich

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

[Anthony G. Basile]

On 09/06/14 08:41, Patrick Lauer wrote:
> On Friday 05 September 2014 12:34:11 William Hubbs wrote:
>> All,
>>
>> there is a bug open requesting that we add sys-apps/iproute2 to the
>> system set [1]. Originally the request was to drop net-tools, but it has
>> become just adding iproute2.
> I wouldn't mind either option - net-tools has been deprecated for a decade,
> but if we still ship it as default it will be used.
>
> Some people seem to think that stage3 is bloated - last time I looked at it
> there was lots of really-not-needed stuff like two python interpreters. If you
> want to de-bloat work on that, the extra 150kB or whatever of iproute2 are so
> small that it's barely noticeable.
I'm not sure we can get rid of python2 and have only python3, but if 
that's possible, absolutely punt it!  The bloat I'm talking about 
includes size, but more importantly, I'm concerned about cpu time. When 
building on a minor arch where your CPU speed is 600 MHz and you only 
have 256MB of ram (and lots of slow swap to help for monsters like 
gcc-4.8), you feel the bloat in days of waiting.

>
> And by the same reasoning of "bloat" we should remove openssh ( and maybe even
> rsync ;) ) because it's not strictly needed - so maybe we want a "minimal" and
> a "useful" stage3 ?

This begs the question "useful for what"?   We have competing criteria.  
So one criterion is "a final stage in a catalyst run which can seed the 
next round" and the other is "a stage from which any gentoo system can 
be built."  Both depend on the environment in which you are building, 
eg. if you unpack a stage3 onto a partition, reboot, and then expect to 
be able to rsync portage, then you need rsync in there, and maybe some 
other stuff like wget or curl. Alternatively, I could build up my system 
in a chroot in which I bind mount /usr/portage from the host, the way 
catalyst does --  its a bit more complicated than that but you get the 
idea.  Then I don't need rsync.

So yeah, there is a slippery slope here, but having two packages that 
achieve the same purpose is overstepping.  The better analogy would be 
having openssh and dropbear and then saying that the latter is only 
150kB, so let's just add it.

>
> Have fun,
>
> Patrick
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Rich Freeman]

On Sat, Sep 6, 2014 at 9:23 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
>
> I'm not sure we can get rid of python2 and have only python3, but if that's
> possible, absolutely punt it!  The bloat I'm talking about includes size,
> but more importantly, I'm concerned about cpu time. When building on a minor
> arch where your CPU speed is 600 MHz and you only have 256MB of ram (and
> lots of slow swap to help for monsters like gcc-4.8), you feel the bloat in
> days of waiting.

The other issue is the parallel build issue.  @system and its deps
can't be built in parallel.  That means a penalty for every update to
any of those packages for life.

Any kind of actual end-user application that goes into @system greatly
compounds this problem.  Applications tend to have lots of
dependencies.

There isn't much question that stuff like rsync and nano (via the
editor virtual) should be in the stage3 just so that we're not ripping
our hair out during installation.  However, they really don't need to
be part of the system set.  How many packages really need to depend on
an editor (and I'm talking linking and other technical issues that
affect builds - not practical use)?  Of course, people probably don't
want to unmerge the last text editor or rsync from their system which
is why it doesn't hurt to have some kind of mix-in that defines
minimally-useful stuff like this all the same, but which separates it
from the practice of not declaring dependencies.

I'm sure all of us have our favorite utilities that we put on every
Gentoo install we do (tmux/screen, atop, vim, etc).  The problem is
that once you go down that road we end up in endless debates.  If we
instead ask questions like "what are all the packages which >30% of
the tree would otherwise have to depend on if not in @system?" or
"what is the minimum set of packages that need to be preinstalled to
build anything else in the tree?" we have unambiguous questions that
have unambiguous answers.

--
Rich

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

[Joshua Kinard]

On 09/06/2014 08:41, Patrick Lauer wrote:
> On Friday 05 September 2014 12:34:11 William Hubbs wrote:
>> All,
>>
>> there is a bug open requesting that we add sys-apps/iproute2 to the
>> system set [1]. Originally the request was to drop net-tools, but it has
>> become just adding iproute2.
> 
> I wouldn't mind either option - net-tools has been deprecated for a decade, 
> but if we still ship it as default it will be used.

It looks like Fedora has been maintaining net-tools on their own now.  We
might want to switch to pulling from their sources, since I know they've
fixed the SCTP bug in netstat -S.  The last official net-tools release on
SourceForge is 2011, so I don't think that's going to be updated anymore.

https://apps.fedoraproject.org/packages/net-tools/overview

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

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

[Joshua Kinard]

On 09/05/2014 13:34, William Hubbs wrote:
> All,
> 
> there is a bug open requesting that we add sys-apps/iproute2 to the
> system set [1]. Originally the request was to drop net-tools, but it has
> become just adding iproute2.
> 
> If no one objects, I would like to do this sometime in the next 72
> hours by adding sys-apps/iproute2 to profiles/default/linux/packages.
> 
> Thoughts?
> 
> William
> 
> [1] https://bugs.gentoo.org/189149

I questioned on the original bug on net-tools vs iproute2, because netstat
and ss each support different protocol families, and so compliment each
other instead of replace.  The same might not hold true for other components
of each package.

That said, the thread had deviated towards discussion on the makeup of the
@system set in general, so let's rename the thread (or at least fork() it).
 IMHO, I think @system should maintain at least one editor and include some
kind of networking diagnostic package.  Even on the slower archs like MIPS,
building either net-tools or iproute2 isn't asking a whole lot.  Faster
archs even less so.  As far as editor, nano is my preference because it just
works for quick edits, but an argument can be made for swapping that out
with a minimal vim (which doesn't require ncurses).

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

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 3:49 PM, Joshua Kinard <kumba@gentoo.org> wrote:
>  IMHO, I think @system should maintain at least one editor and include some
> kind of networking diagnostic package.

Why is it important that we not be able to parallel build an editor?
Is it such a frequent build-time dependency that we wouldn't want to
specify it?  It is essential that we make it extra-hard for a user to
uninstall their last editor, since it is impossible to install an
editor without an editor already present?

I can't imagine using a system without an editor.  I can't imagine
using a system without screen/tmux either.  That doesn't mean that
either belongs in the system set.  I'd be all for keeping it in the
stage3, on the install CDs, and having it in the default @world
though.

This is my concern with @system.  Stuff gets stuck in there for the
noblest of intentions, but it is the wrong solution to the problems it
is being used to solve.

--
Rich

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

[Joshua Kinard]

On 09/07/2014 16:01, Rich Freeman wrote:
> On Sun, Sep 7, 2014 at 3:49 PM, Joshua Kinard <kumba@gentoo.org> wrote:
>> IMHO, I think @system should maintain at least one editor and include 
>> some kind of networking diagnostic package.
> 
> Why is it important that we not be able to parallel build an editor? Is 
> it such a frequent build-time dependency that we wouldn't want to specify
> it?  It is essential that we make it extra-hard for a user to uninstall
> their last editor, since it is impossible to install an editor without an
> editor already present?

Re: editor, I was referring to this:

On 09/06/2014 09:37, Rich Freeman wrote:
> There isn't much question that stuff like rsync and nano (via the
> editor virtual) should be in the stage3 just so that we're not ripping
> our hair out during installation.  However, they really don't need to
> be part of the system set.  How many packages really need to depend on
> an editor (and I'm talking linking and other technical issues that
> affect builds - not practical use)?

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.

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.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

>>>>> On Sun, 07 Sep 2014, Joshua Kinard 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.

There's neither nano nor any other specific editor in the system set,
to start with. There is virtual/editor which I think is the best
choice, unless we would decide that no editor is needed at all.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Joshua Kinard]

On 09/07/2014 16:45, Ulrich Mueller wrote:
>>>>>> On Sun, 07 Sep 2014, Joshua Kinard 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.
> 
> There's neither nano nor any other specific editor in the system set,
> to start with. There is virtual/editor which I think is the best
> choice, unless we would decide that no editor is needed at all.
> 
> Ulrich

The stage2/stage3 catalyst runs I did recently always dragged in nano &
ncurses.  I did very little customization to the build profiles or the
specs, so something was favouring nano over other editors.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

>>>>> On Sun, 07 Sep 2014, Joshua Kinard wrote:

> On 09/07/2014 16:45, Ulrich Mueller wrote:
>> There's neither nano nor any other specific editor in the system set,
>> to start with. There is virtual/editor which I think is the best
>> choice, unless we would decide that no editor is needed at all.

> The stage2/stage3 catalyst runs I did recently always dragged in nano &
> ncurses.  I did very little customization to the build profiles or the
> specs, so something was favouring nano over other editors.

nano is preferred because it appears first in the list of dependencies
in virtual/editor.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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@gentoo.org> 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

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

[Joshua Kinard]

On 09/07/2014 17:04, Rich Freeman wrote:
> On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard <kumba@gentoo.org> 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.

Well, I was mainly just trying to fork() the thread to discuss the @system
issue in general, so the smaller issue of net-tools vs iproute2 could be
discussed and the bug resolved appropriately.  I looked over the
base/packages file and that looks fine to me right now.  Couple of
commented-out lines can probably be removed, but even on my slow MIPS
systems, a full stage1-stage2-stage3 run only takes about 2.5 days, so I
really don't have a problem with the current makeup of @system, and adding
iproute2 to it isn't going to really change much.

As I highlighted in the bug, only comparing netstat and ss (which is far
from a comprehensive analysis), they compliment each other instead of
replace.  netstat supports older protocol families like IPX and AX.25 (some
HAMs using Linux still use this), plus it supports showing SCTP sockets via
the undocumented -S flag, as well as UDPLite.  But, the SCTP support is
currently broken, and Fedora's patches should fix it.  ss, on the other
hand, does not support SCTP, but does support DCCP (the other IANA
general-purpose protocol), which netstat doesn't.

Undoubtedly, there are other variances between the two packages.  Before one
replaces the other, we should take a look at what each package offers, find
the places where they compliment each other and push whichever one has the
active upstream to incorporate the missing features (likely, iproute2 needs
to pickup UDPLite and SCTP support), then we can replace one with the other.

As for net-tools itself, I'll see if I can get Fedora's patches to apply to
it and update it.  If not, I dunno whether to import their version as a
separate package or as an alternate version (net-tools-2.0?).  No point in
ignoring it when there's obvious bugs and fixes available, even if they're
not from the original upstream.


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


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


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

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

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

[Joshua Kinard]

On 09/07/2014 17:57, Joshua Kinard wrote:
> 
> As for net-tools itself, I'll see if I can get Fedora's patches to apply to
> it and update it.  If not, I dunno whether to import their version as a
> separate package or as an alternate version (net-tools-2.0?).  No point in
> ignoring it when there's obvious bugs and fixes available, even if they're
> not from the original upstream.

Added net-tools-1.60_p20130513023548-r1.ebuild, please test.

Previous: netstat -anSp:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address  Foreign Address   State   PID/Program name
sctp       0      0 0.0.0.0:22     0.0.0.0:*         LISTEN  18500/sshd
SCTP error in line: 2
      Bug ^^^^^^

Now:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address  Foreign Address   State   PID/Program name
sctp                0.0.0.0:22                       LISTEN  18500/sshd
sctp                :::22                            LISTEN  18500/sshd

(Yes, the re-written SCTP stats code from Fedora don't display a value when
0 or nothing is connected -- no idea why).


IPX addresses are also displayed correctly:
Active IPX sockets
Proto Recv-Q Send-Q Local Address    Foreign Address            State
IPX        0      0 01000000:0540    -
IPX        0      0 01000000:0440    -
IPX        0      0 01000000:0340    3E01A8C0:000000000001:5104 ESTAB
                                     ^^^^^^^^
Now:
Active IPX sockets
Proto Recv-Q Send-Q Local Address    Foreign Address            State
IPX        0      0 00000001:0540    -
IPX        0      0 00000001:0440    -
IPX        0      0 00000001:0340    C0A8013E:000000000001:5104 ESTAB
                                     ^^^^^^^^

If anyone encounters any problems, please let me know.

Thanks!,

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

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

[J. Roeleveld]

[-- Attachment #1: Type: text/plain, Size: 3015 bytes --]


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 <kumba@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

[-- Attachment #2: Type: text/html, Size: 12300 bytes --]

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

[Duncan]

J. Roeleveld posted on Wed, 10 Sep 2014 10:08:56 +0200 as excerpted:

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

FWIW I keep both my preferred editor (MC, FWIW) and nano installed.

That way I have a backup if my preferred fails to start (as it does from 
time to time if I'm rebuilding deps), and I don't end up having to use a 
pager and sed in place of a proper interactive editor, as I did at one 
point many years ago on a different distro.  (It probably had vim-minimal 
or some such, but I was still young on Linux at that point and didn't 
know what to look for.  Fortunately I had a dead-tree copy of Linux in a 
Nutshell around, with an appendix on sed that I could refer to...)


-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[Rich Freeman]

On Wed, Sep 10, 2014 at 4:08 AM, J. Roeleveld <joost@antarean.org> wrote:
>
> But on slower machines, as I am used to fast ones, I tend to notice the lack
> of parallellism during the emerge-phase.
>

Diego used to point out that lack of parallelism was always a
challenge with running a tinderbox.  You can have 32 cores in your
machine but it doesn't help when half the packages you want to build
end up being a single-threaded task.

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

Again, I think we need to stop thinking @system = stage3 = livecd.
What goes into the stage3 and what goes into @system should be two
different things.  Having an editor at install time is a no-brainer.

--
Rich