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