On Sat, Dec 7, 2013 at 12:52 AM, Rick "Zero_Chaos" Farina <zeroch...@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
