On 09/06/14 07:05, Rich Freeman wrote:
On Sat, Sep 6, 2014 at 2:44 AM, Duncan <1i5t5.dun...@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 : bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
