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@×××.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@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA