On Fri, Aug 31, 2012 at 2:56 PM, Mike Gilbert <flop...@gentoo.org> wrote: > On Fri, Aug 31, 2012 at 2:16 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> Thus, not adding it to @system in no way means it's not considered >> mandatory for a normal install, it just means the ultimate goal is to >> have all the deps specified and nothing left in @system, and while >> progress isn't fast by a long shot, the first thing is to ensure we're >> not regressing! >> > > If the ultimate goal is to eliminate @system entirely (which it > probably isn't), we will need to revisit the way stage building works. > If understand correctly, a stage3 contains @system and its > dependencies.
The goal would be to eliminate @system entirely. The solution to stage3 would be to have a set like @system of default starting packages. It might even be a defined set that users could make use of (emerge @default), but ebuilds could not assume that they are present. To build them you just start with a working Gentoo system and emerge them. > > The smallest you can really make @system under that circumstance would > be a working toolchain and the utilities necessary to build any other > needed packages. I think that is the goal that most people have been > shooting for lately. Nobody is suggesting that a system containing no packages whatsoever should be bootable, let alone usable to bootstrap everything else. There would be some minimal set of packages needed to bootstrap the rest. However, ebuilds would need to explicitly declare their need for them rather than assuming they are present. Virtuals could be used to simplify this. In fact, there is a simple way to transition to such a system. Start by defining a virtual that contains everything that is in @system (setting aside the issue that this is profile-dependent), and adding that as a DEPEND and RDEPEND to every ebuild. Then start paring it down per-ebuild. The goal is not to have working Gentoo systems that contain nothing on their hard drives, but rather to eliminate the arbitrary collection of packages that must be present everywhere, because some software that might or might not even be installed could need them. Rich
