On Wednesday, October 26, 2016 11:14:53 PM Rich Freeman wrote: > On Wed, Oct 26, 2016 at 10:54 PM, Walter Dnes <waltd...@waltdnes.org> wrote: > > On Thu, Oct 27, 2016 at 01:10:10AM +0000, Peter Stuge wrote > > > >> waltd...@waltdnes.org wrote: > >> > For a build-from-source distro like Gentoo, gcc and associated > >> > tools are a vital part of the distro. > >> > >> A stage4 created (and updated) on a catalyst build farm doesn't need > >> to have gcc, but may still need libstdc++. > >> > > That just moves the requirement for gcc+tools to the catalyst build > > > > farm. OK, let's get specific... a *STANDALONE* Gentoo machine requires > > gcc+tools. > > This is why I think "@system" oversimplifies all of this. IMO we > should just specify all dependencies for everything (and those could > include some virtuals for convenience, like the C toolchain), and then > have different sets or virtuals for convenience. By all means give a > user with a default install that sticks virtual/common-packages or > something in their @world. Nobody is arguing that the typical Gentoo > user doesn't want gcc, or that we should force people to explicitly > install it. > > Fixing the dependencies means that system packages can take advantage > of parallel builds, which means faster updates for everybody. We can > still have sets for bootstraping (and I suspect that having more > virtuals or sets would allow stage1/2 definition to be simplified). > > It is a bit like license groups. We give everybody a default set of > license groups that generally makes sense. But, if you want you can > easily edit your make.conf to exclude anything that is copyleft from > your system. > > The main downside to this is it is a bit more of a hassle for > developers to maintain the dependency lists, since invariably you end > up with a lot of mundane stuff in there. And of course it is a lot of > change to implement, though it could be done gradually. And of course > the upside for the typcal user is somewhat limited, since most people > aren't dying to uninstall openssh or gcc.
I want to +1 this, but I do see one problem: If all dependencies are defined, how does "emerge --with-bdeps=y --emptytree @world" work? Defining all dependencies means the graph is completely cyclic. Perhaps the answer is that it doesn't; you have to run 'emerge --emptytree @world twice' if you want to ensure every package is rebuilt with its newest available build dependencies. I'll sometimes do an "emerge -e @world" twice following a compiler upgrade or CFLAGS or LDFLAGS change. -- :wq
signature.asc
Description: This is a digitally signed message part.
