On 03/12/13 23:11, William Hubbs wrote: > On Tue, Dec 03, 2013 at 09:32:10PM +0400, Alexander V Vershilov wrote: >> On Dec 3, 2013 1:24 AM, "Ian Stakenvicius" <a...@gentoo.org> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> On 02/12/13 04:19 PM, Rick "Zero_Chaos" Farina wrote: >>>> On 12/02/2013 03:28 PM, William Hubbs wrote: [...] >>>>> Also, the other message in this thread is correct; the netifrc >>>>> use flag is temporary. >>>>> I originally planned to release openrc-0.12.x along with a >>>>> newsitem that instructed you to emerge the netifrc package if you >>>>> want the legacy network stack, but some users/devs felt that >>>>> Ishould go further to make sure netifrc remains installed on >>>>> their systems. >>>> As one of those devs, I feel now may be a good time to ask.... What >>>> are we doing about this? In my opinion, anyone removing net >>>> support from the stage3's should be killed with fire. That said, I >>>> don't care if it's netifrc or whatever as long as it is properly >>>> documented and actually usable. >>>> >>>> Thoughts on how we move forward? >>>> >>>> Thanks, Zero >>>> >>> Well, part of this conversation needs to be, what is the default >>> networking stack that we want to have in gentoo? IMO that should >>> remain netifrc but that's just my personal opinion. >> I personally like netifrc default but there is no good way to use it as >> default we will need to keep use flag arbitrary long or add netifrc to >> @system but it will return us back to the problems of users who doesn't >> want to have netifrc on their systems. And with the rise of systems and NM >> the number of such users will grow. Anyway I'd like to see base system herd >> vote. > I would like to add a virtual/network-manager package to @system which > has the following rdepend settings: > > RDEPEND=" || ( > net-misc/netifrc > >=sys-apps/openrc-0.12[newnet] > net-misc/badvpn > net-misc/dhcpcd > net-misc/netctl > net-misc/NetworkManager > net-misc/wicd )" > > Does anyone see an issue with setting it up this way? >
seems like a virtual that wouldn't do anything useful except pull in random package(s) a la binary-distribution style just update the handbook to include the 'emerge netifrc' step and mention it's just one possibility