Re: [gentoo-dev] Commented packages in the @system set

[Michael Mol]

On Wednesday, October 26, 2016 11:14:53 PM Rich Freeman wrote:
> On Wed, Oct 26, 2016 at 10:54 PM, Walter Dnes <waltdnes@××××××××.org> wrote:
> > On Thu, Oct 27, 2016 at 01:10:10AM +0000, Peter Stuge wrote
> >
> >> 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