Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up

[Rich Freeman <rich0@gentoo.org>]

On Sat, Dec 7, 2013 at 12:52 AM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
>
> 2.) having dhcpcd in this list will cause everything else to be cleaned
> out that that is baaaad.  imho, dhcpcd shouldn't be on this list at all
> purely from a safety perspective.  The stages will have dhcpcd so they
> wouldn't end up with netifrc afaict.

The problem is that dhcpcd can be used either as a network manager, or
as a utility employed by a network manager.  I'm not sure how use deps
in virtuals work - if you could make the dependency on
dhcpcd[network-manager] and not have portage try to get the user to
change the config of dhcpcd if something else on the list is
installed.  The use flag wouldn't do anything, it would just be a
message to portage that you intend to use dhcpcd as the network
manager.

But you could just as easily have the user do all of this manually -
we don't have a kernel virtual to try to get the user to install a
kernel.

> Honestly, I'm not really sure why anyone would want to make stage3 less
> functional than it already is but honestly net isn't something I'm ready
> to give up just yet.

It isn't about making the stage3 less functional, but about giving the
user a choice.  We don't stick a kernel in stage3, despite the fact
that everybody needs one.  We don't stick an MTA in the stage3 despite
the fact that one of those is pretty hard to live without.

Now that Gentoo apparently offers a wide selection of network
managers, perhaps it makes sense to have the user pick which one they
want to use.

IMHO the purpose of @system and the stage3 is to solve the circular
dependency problem inherent in bootstrapping.  It really shouldn't
contain anything beyond this.  By all means have an @useful-utils set
or some kind of profile that auto-installs a list of packages like
openssh, vim, and so on.  However, these are not required to bootstrap
a system and I'm not sure why we should be forcing them into the
@system set as a result.

Another option would be to have things installed in the stage3 that
are not part of the @system set, so that they would be depcleaned at a
later date.  I'm not a big fan of that, however, mainly because it
could be a curve-ball for somebody to deal with after they think
they've gotten everything working.  I think users will have a better
understanding of how their system is set up if they put things there
than if things start out there but get yanked out from under them.

Rich