| 1 |
On Sat, Dec 7, 2013 at 12:52 AM, Rick "Zero_Chaos" Farina |
| 2 |
<zerochaos@g.o> wrote: |
| 3 |
> |
| 4 |
> 2.) having dhcpcd in this list will cause everything else to be cleaned |
| 5 |
> out that that is baaaad. imho, dhcpcd shouldn't be on this list at all |
| 6 |
> purely from a safety perspective. The stages will have dhcpcd so they |
| 7 |
> wouldn't end up with netifrc afaict. |
| 8 |
|
| 9 |
The problem is that dhcpcd can be used either as a network manager, or |
| 10 |
as a utility employed by a network manager. I'm not sure how use deps |
| 11 |
in virtuals work - if you could make the dependency on |
| 12 |
dhcpcd[network-manager] and not have portage try to get the user to |
| 13 |
change the config of dhcpcd if something else on the list is |
| 14 |
installed. The use flag wouldn't do anything, it would just be a |
| 15 |
message to portage that you intend to use dhcpcd as the network |
| 16 |
manager. |
| 17 |
|
| 18 |
But you could just as easily have the user do all of this manually - |
| 19 |
we don't have a kernel virtual to try to get the user to install a |
| 20 |
kernel. |
| 21 |
|
| 22 |
> Honestly, I'm not really sure why anyone would want to make stage3 less |
| 23 |
> functional than it already is but honestly net isn't something I'm ready |
| 24 |
> to give up just yet. |
| 25 |
|
| 26 |
It isn't about making the stage3 less functional, but about giving the |
| 27 |
user a choice. We don't stick a kernel in stage3, despite the fact |
| 28 |
that everybody needs one. We don't stick an MTA in the stage3 despite |
| 29 |
the fact that one of those is pretty hard to live without. |
| 30 |
|
| 31 |
Now that Gentoo apparently offers a wide selection of network |
| 32 |
managers, perhaps it makes sense to have the user pick which one they |
| 33 |
want to use. |
| 34 |
|
| 35 |
IMHO the purpose of @system and the stage3 is to solve the circular |
| 36 |
dependency problem inherent in bootstrapping. It really shouldn't |
| 37 |
contain anything beyond this. By all means have an @useful-utils set |
| 38 |
or some kind of profile that auto-installs a list of packages like |
| 39 |
openssh, vim, and so on. However, these are not required to bootstrap |
| 40 |
a system and I'm not sure why we should be forcing them into the |
| 41 |
@system set as a result. |
| 42 |
|
| 43 |
Another option would be to have things installed in the stage3 that |
| 44 |
are not part of the @system set, so that they would be depcleaned at a |
| 45 |
later date. I'm not a big fan of that, however, mainly because it |
| 46 |
could be a curve-ball for somebody to deal with after they think |
| 47 |
they've gotten everything working. I think users will have a better |
| 48 |
understanding of how their system is set up if they put things there |
| 49 |
than if things start out there but get yanked out from under them. |
| 50 |
|
| 51 |
Rich |
Archives