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

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

[Alessandro DE LAURENZIS]

I've just upgraded to the latest openrc version; I was aware of the
netifrc USE flag introduction
(http://www.gossamer-threads.com/lists/gentoo/user/275748). But so far
the presence of the newnet flag was actually a "switch" between the old
and the new network stack, given that one of the two should (must?) be
added in any case.
Now the presence of both netifrc and newnet could make a bit of
confusion, particularly from a user perspective. We have of course 4
cases; two of them are clear:
1) netifrc -newnet: "legacy" network stack;
2) -netifrc newnet: "new" network stack.

The other two cases need a clarification:
3) -netifrc -newnet: no network stack?!?
4) netifrc newnet: ???

This should be definitely documented somewhere (I didn't find anything).

And, the last question: what's the point to have two flags instead the
good old one?

Thanks for any clarification.

-- 
Alessandro DE LAURENZIS
[mailto:just22.adl@gmail.com]
LinkedIn: http://it.linkedin.com/in/delaurenzis

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

[Alexander V Vershilov]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

The only one unclear case is 4 (+netifrc +newnet) in this case stack that
is used is set by enabling required stack by rc-update. Case 3 means that
openrc doesn't provide default network stack and it's up to user which
stack to use (e.g. NM), so no problem here.
Also +netifrc flag is temporal to make update path clean and it may be
removed in future.
 On Dec 1, 2013 2:20 PM, "Alessandro DE LAURENZIS" <just22.adl@gmail.com>
wrote:

> I've just upgraded to the latest openrc version; I was aware of the
> netifrc USE flag introduction
> (http://www.gossamer-threads.com/lists/gentoo/user/275748). But so far
> the presence of the newnet flag was actually a "switch" between the old
> and the new network stack, given that one of the two should (must?) be
> added in any case.
> Now the presence of both netifrc and newnet could make a bit of
> confusion, particularly from a user perspective. We have of course 4
> cases; two of them are clear:
> 1) netifrc -newnet: "legacy" network stack;
> 2) -netifrc newnet: "new" network stack.
>
> The other two cases need a clarification:
> 3) -netifrc -newnet: no network stack?!?
> 4) netifrc newnet: ???
>
> This should be definitely documented somewhere (I didn't find anything).
>
> And, the last question: what's the point to have two flags instead the
> good old one?
>
> Thanks for any clarification.
>
> --
> Alessandro DE LAURENZIS
> [mailto:just22.adl@gmail.com]
> LinkedIn: http://it.linkedin.com/in/delaurenzis
>
>

[-- Attachment #2: Type: text/html, Size: 2066 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Sun, Dec 01, 2013 at 11:20:15AM +0100, Alessandro DE LAURENZIS wrote:

*snip*

> The other two cases need a clarification:
> 3) -netifrc -newnet: no network stack?!?

That's correct, you do not need one if you are using something like
networkmanager or dhcpcd in master mode.

> 4) netifrc newnet: ???

Both would be installed, but you still have to configure the one you
want to use.

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.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/02/2013 03:28 PM, William Hubbs wrote:
> On Sun, Dec 01, 2013 at 11:20:15AM +0100, Alessandro DE LAURENZIS wrote:
> 
> *snip*
> 
>> The other two cases need a clarification:
>> 3) -netifrc -newnet: no network stack?!?
> 
> That's correct, you do not need one if you are using something like
> networkmanager or dhcpcd in master mode.
> 
>> 4) netifrc newnet: ???
> 
> Both would be installed, but you still have to configure the one you
> want to use.
> 
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSnPlzAAoJEKXdFCfdEflKX04P/jV742c4/2/T+LKqpNiu4Q1V
tRRjBxbAo679MkjMdSsETzeT87jE5QtGGmsua9lcIP93WU28Qik8PRtXl74mpJav
83leOqnI5iis1TJml1MHoco5FIFIB5cC/QQ5xOFTgaEZhY+f9r8/hzxG+xXRyaW/
X+PRmj167rTrs9Yzp7VINjbo+EqUxtOUqzFQySK6uW89cQB1HUDgZ9SKIey3f1PY
KiTQbb16o7a6XXP3CwQOZGinwo8VJvIdxx9CypSdBXoIE6A/G2ux0HSjzs+8HeWO
s9OO3Pa9ptX8JxyRtd2Y18CYLoAmc7ecLupyOqpvLptVG7r38iaP93D6+89IN7Kp
WYv/UBbyMOLE4voZotRUHeKb5Dtl69nir9JvfohQTavs7gXLQca3BHAXMLOfbjYf
jokGdE5OqQQHwn1Bokl2+4blIYY+FDKrh+0osqe4T2Nk02wli5/6IiThVk5kttJl
MXzqh2+1Oz+jtp1F2pTsP3hJUuV6sdtHiunXNKicyDSCYrZIadXtA+DB2gImmvHD
HWnfomYlqZnKUs+lxwh4FM56O5NzpVnWxiA4Xx8K8Rgq5i8bCUiluxZgKTwBPyk8
c4EUllyp7u0mZCNL90XH6aeLIWXcI8vPW7K4sgsG0fhxWSGDQCIYQLRe/86MCWKh
bCCtQC4u5/IlGO5NDKw5
=ripZ
-----END PGP SIGNATURE-----

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

[Ian Stakenvicius]

-----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.

After deciding that, I expect we should decide how to include it.  My
guess would be, since for whatever reason we don't want netifrc as
part of @system or a dep of baselayout-2 or anything like that, we'd
need to add it to the special releng include list?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlKc+qEACgkQ2ugaI38ACPAu6AD/RpeD8NsMsjt4X5EKYe6Tkixu
6qzCONtd44U+grcxKr0BALw1EaxdI/EQ+Fo3eASssQ8fUH/dRFus5EUPo46dPz0L
=Bmfz
-----END PGP SIGNATURE-----

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

[Alexander V Vershilov]

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

On Dec 3, 2013 1:24 AM, "Ian Stakenvicius" <axs@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.
>
> After deciding that, I expect we should decide how to include it.  My
> guess would be, since for whatever reason we don't want netifrc as
> part of @system or a dep of baselayout-2 or anything like that, we'd
> need to add it to the special releng include list?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iF4EAREIAAYFAlKc+qEACgkQ2ugaI38ACPAu6AD/RpeD8NsMsjt4X5EKYe6Tkixu
> 6qzCONtd44U+grcxKr0BALw1EaxdI/EQ+Fo3eASssQ8fUH/dRFus5EUPo46dPz0L
> =Bmfz
> -----END PGP SIGNATURE-----
>

[-- Attachment #2: Type: text/html, Size: 2646 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]

On Tue, Dec 03, 2013 at 09:32:10PM +0400, Alexander V Vershilov wrote:
> On Dec 3, 2013 1:24 AM, "Ian Stakenvicius" <axs@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?

	William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ian Stakenvicius]

On 2013-12-03, at 4:11 PM, William Hubbs <williamh@gentoo.org> wrote:

> On Tue, Dec 03, 2013 at 09:32:10PM +0400, Alexander V Vershilov wrote:
>> On Dec 3, 2013 1:24 AM, "Ian Stakenvicius" <axs@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?
> 
>    William
> 

well, there is the issue where dhcpcd being installed (which is common for netifrc support) is going to allow netifrc to be cleaned...  similar for NM and Wicd I expect, if those aren't in @world ....

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

On Tue, Dec 03, 2013 at 04:43:28PM -0500, Ian Stakenvicius wrote:
> On 2013-12-03, at 4:11 PM, William Hubbs <williamh@gentoo.org> wrote:
> > 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?
> > 
> >    William
> > 
> 
> well, there is the issue where dhcpcd being installed (which is common
> for netifrc support) is going to allow netifrc to be cleaned... 
> similar for NM and Wicd I expect, if those aren't in @world ....

Please correct me if I am wrong. You can install NM or wicd and
remove netifrc and have a working system, correct?

Dhcpcd can be run as a standalone service or per interface. In
standalone mode, the default is to automatically configure any unconfigured
interfaces it finds on your system, but this can be configured (see
dhcpcd.conf (5)). So, I'm wondering what the advantage of running dhcpcd
per interface is?

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ian Stakenvicius]

On 2013-12-03, at 6:00 PM, William Hubbs <williamh@gentoo.org> wrote:

> On Tue, Dec 03, 2013 at 04:43:28PM -0500, Ian Stakenvicius wrote:
>> On 2013-12-03, at 4:11 PM, William Hubbs <williamh@gentoo.org> wrote:
>>> 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?
>>> 
>>>   William
>> 
>> well, there is the issue where dhcpcd being installed (which is common
>> for netifrc support) is going to allow netifrc to be cleaned... 
>> similar for NM and Wicd I expect, if those aren't in @world ....
> 
> Please correct me if I am wrong. You can install NM or wicd and
> remove netifrc and have a working system, correct?
> 
> Dhcpcd can be run as a standalone service or per interface. In
> standalone mode, the default is to automatically configure any unconfigured
> interfaces it finds on your system, but this can be configured (see
> dhcpcd.conf (5)). So, I'm wondering what the advantage of running dhcpcd
> per interface is?
> 
> William
> 

I'm just referring to issues with selecting  the networking stack via a virtual, is all. it'a nice that netifrc is the default due to being on top, but I expect many ppl that run netifrc use dhcp to config at least one iface, and emerging dhcpcd will then bump it out due to it now satisfying the virtual.  Maybe a use flag "dhcp-only" that excludes dhcpcd from the virtual list unless set??

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

[mingdao]

On Tue, Dec 03, 2013 at 03:11:30PM -0600, William Hubbs wrote:
> 
> 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?
> 
> 	William

Just curious why you don't also include net-misc/connman?

wicd doesn't support nl80211 and isn't being developed upstream anymore, so
it's just a matter of time before it's demise.

Cheers,
Bruce
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 372 bytes --]

On Tue, Dec 03, 2013 at 07:14:37PM -0600, mingdao wrote:
> 
> Just curious why you don't also include net-misc/connman?
> 
> wicd doesn't support nl80211 and isn't being developed upstream anymore, so
> it's just a matter of time before it's demise.

I didn't include connman only because I didn't know about it. :-)

It will be added. :-)

Thanks,

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Samuli Suominen]

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" <axs@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

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
> seems like a virtual that wouldn't do anything useful except pull in
> random package(s) a la binary-distribution style

What about the stages? Don't we need some form of net support in
stage 3?

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Mike Gilbert]

On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
>> seems like a virtual that wouldn't do anything useful except pull in
>> random package(s) a la binary-distribution style
>
> What about the stages? Don't we need some form of net support in
> stage 3?
>

That's debatable. For a typical install, the user has to install other
basic stuff like a boot loader, kernel, etc. So having them also
select a network config framework seems logical.

Is there a use case for a stage3 in which installing netifrc by hand
is impractical?

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

On Wed, Dec 04, 2013 at 04:30:30PM -0500, Mike Gilbert wrote:
> On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs <williamh@gentoo.org> wrote:
> > On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
> >> seems like a virtual that wouldn't do anything useful except pull in
> >> random package(s) a la binary-distribution style
> >
> > What about the stages? Don't we need some form of net support in
> > stage 3?
> >
> 
> That's debatable. For a typical install, the user has to install other
> basic stuff like a boot loader, kernel, etc. So having them also
> select a network config framework seems logical.
> 
> Is there a use case for a stage3 in which installing netifrc by hand
> is impractical?

Personally, I don't know of one. Does anyone else?

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Mike Gilbert]

On Wed, Dec 4, 2013 at 5:31 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Wed, Dec 04, 2013 at 04:30:30PM -0500, Mike Gilbert wrote:
>> On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs <williamh@gentoo.org> wrote:
>> > On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
>> >> seems like a virtual that wouldn't do anything useful except pull in
>> >> random package(s) a la binary-distribution style
>> >
>> > What about the stages? Don't we need some form of net support in
>> > stage 3?
>> >
>>
>> That's debatable. For a typical install, the user has to install other
>> basic stuff like a boot loader, kernel, etc. So having them also
>> select a network config framework seems logical.
>>
>> Is there a use case for a stage3 in which installing netifrc by hand
>> is impractical?
>
> Personally, I don't know of one. Does anyone else?
>

Thinking on this further, the same logic could be applied to
sys-apps/openrc, and probably a few other packages that are not
build/toolchain critical. I suppose we need to draw a sanity line
somewhere. ^_^

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

On Wed, Dec 04, 2013 at 05:36:37PM -0500, Mike Gilbert wrote:
> Thinking on this further, the same logic could be applied to
> sys-apps/openrc, and probably a few other packages that are not
> build/toolchain critical. I suppose we need to draw a sanity line
> somewhere. ^_^

I think what you are talking about is going through @system and cleaning
out unnecessary virtuals, or other packages. This is an interesting
topic, but should be a separate thread imo.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Samuli Suominen]

On 05/12/13 00:36, Mike Gilbert wrote:
> On Wed, Dec 4, 2013 at 5:31 PM, William Hubbs <williamh@gentoo.org> wrote:
>> On Wed, Dec 04, 2013 at 04:30:30PM -0500, Mike Gilbert wrote:
>>> On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs <williamh@gentoo.org> wrote:
>>>> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
>>>>> seems like a virtual that wouldn't do anything useful except pull in
>>>>> random package(s) a la binary-distribution style
>>>> What about the stages? Don't we need some form of net support in
>>>> stage 3?
>>>>
>>> That's debatable. For a typical install, the user has to install other
>>> basic stuff like a boot loader, kernel, etc. So having them also
>>> select a network config framework seems logical.
>>>
>>> Is there a use case for a stage3 in which installing netifrc by hand
>>> is impractical?
>> Personally, I don't know of one. Does anyone else?
>>
> Thinking on this further, the same logic could be applied to
> sys-apps/openrc, and probably a few other packages that are not
> build/toolchain critical. I suppose we need to draw a sanity line
> somewhere. ^_^
>

indeed. it just looks clear the line has moved a bit with all these
modern networking setup tools coming around,
so let's redefine where the line is drawn accordingly.

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

[Martin Gysel]

Am 04.12.2013 23:31, schrieb William Hubbs:
> On Wed, Dec 04, 2013 at 04:30:30PM -0500, Mike Gilbert wrote:
>> On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs <williamh@gentoo.org> wrote:
>>> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
>>>> seems like a virtual that wouldn't do anything useful except pull in
>>>> random package(s) a la binary-distribution style
>>>
>>> What about the stages? Don't we need some form of net support in
>>> stage 3?
>>>
>>
>> That's debatable. For a typical install, the user has to install other
>> basic stuff like a boot loader, kernel, etc. So having them also
>> select a network config framework seems logical.
>>
>> Is there a use case for a stage3 in which installing netifrc by hand
>> is impractical?
> 
> Personally, I don't know of one. Does anyone else?

if you're on x86/amd64 and want to prepare a sdcard for e.g. arm. you
extract the stage3 to the card but then you can't just chroot and emerge
netifrc...
on the other hand, as long as busybox' default config includes a dhcp
client one can always call it manually, unfortunately to do so. you need
to have access to the system which isn't always guaranteed without network.
so I strongly vote against exclude a default network stack for stage3.
why not introduce a stage3 set which includes @system and other
important packages like the default network stack?

/martin

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

[Steev Klimaszewski]

On Thu, 2013-12-05 at 09:01 +0100, Martin Gysel wrote:

> if you're on x86/amd64 and want to prepare a sdcard for e.g. arm. you
> extract the stage3 to the card but then you can't just chroot and emerge
> netifrc...
> on the other hand, as long as busybox' default config includes a dhcp
> client one can always call it manually, unfortunately to do so. you need
> to have access to the system which isn't always guaranteed without network.
> so I strongly vote against exclude a default network stack for stage3.
> why not introduce a stage3 set which includes @system and other
> important packages like the default network stack?
> 
> /martin

Actually, it's quite easy to chroot into an arm rootfs on amd64/x86 if
you have qemu or qemu-user installed.  I do this on a daily basis.  It's
really not difficult at all.

-- Steev

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

[Patrick Lauer]

On 12/05/2013 05:30 AM, Mike Gilbert wrote:
> On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs <williamh@gentoo.org> wrote:
>> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
>>> seems like a virtual that wouldn't do anything useful except pull in
>>> random package(s) a la binary-distribution style
>>
>> What about the stages? Don't we need some form of net support in
>> stage 3?
>>
> 
> That's debatable. For a typical install, the user has to install other
> basic stuff like a boot loader, kernel, etc. So having them also
> select a network config framework seems logical.
> 
> Is there a use case for a stage3 in which installing netifrc by hand
> is impractical?
> 
Well ...

I remember filing a bug quite a while ago because we didn't have a dhcp
client included anymore. This made installs quite annoying because
before it was stage3, kernel, bootloader, go!

And now it was go ... stop ... reboot ... install dhcp client ...
grremblwrrxrmkrxtlmrrrg .... reboot

That extra step of whining was loud enough to have openrc fixed to be
able to use busybox udhcp, so that "out of the box" most network worked.

... and now people are trying to do the same again.

I would STRONGLY recommend having a working network setup included in
stage3, so that compared to now nothing changes.

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

On Thu, Dec 05, 2013 at 07:45:22AM +0800, Patrick Lauer wrote:
> On 12/05/2013 05:30 AM, Mike Gilbert wrote:
> > On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs <williamh@gentoo.org> wrote:
> >> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
> >>> seems like a virtual that wouldn't do anything useful except pull in
> >>> random package(s) a la binary-distribution style
> >>
> >> What about the stages? Don't we need some form of net support in
> >> stage 3?
> >>
> > 
> > That's debatable. For a typical install, the user has to install other
> > basic stuff like a boot loader, kernel, etc. So having them also
> > select a network config framework seems logical.
> > 
> > Is there a use case for a stage3 in which installing netifrc by hand
> > is impractical?
> > 
> Well ...
> 
> I remember filing a bug quite a while ago because we didn't have a dhcp
> client included anymore. This made installs quite annoying because
> before it was stage3, kernel, bootloader, go!
> 
> And now it was go ... stop ... reboot ... install dhcp client ...
> grremblwrrxrmkrxtlmrrrg .... reboot

Are you sure this was caused by an issue in the stages? The description
you are giving sounds like an issue with the LiveCD.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Patrick Lauer]

On 12/05/2013 08:13 AM, William Hubbs wrote:
> On Thu, Dec 05, 2013 at 07:45:22AM +0800, Patrick Lauer wrote:
>> On 12/05/2013 05:30 AM, Mike Gilbert wrote:
>>> On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs <williamh@gentoo.org> wrote:
>>>> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
>>>>> seems like a virtual that wouldn't do anything useful except pull in
>>>>> random package(s) a la binary-distribution style
>>>>
>>>> What about the stages? Don't we need some form of net support in
>>>> stage 3?
>>>>
>>>
>>> That's debatable. For a typical install, the user has to install other
>>> basic stuff like a boot loader, kernel, etc. So having them also
>>> select a network config framework seems logical.
>>>
>>> Is there a use case for a stage3 in which installing netifrc by hand
>>> is impractical?
>>>
>> Well ...
>>
>> I remember filing a bug quite a while ago because we didn't have a dhcp
>> client included anymore. This made installs quite annoying because
>> before it was stage3, kernel, bootloader, go!
>>
>> And now it was go ... stop ... reboot ... install dhcp client ...
>> grremblwrrxrmkrxtlmrrrg .... reboot
> 
> Are you sure this was caused by an issue in the stages? The description
> you are giving sounds like an issue with the LiveCD.
> 
> William
> 
Yes ... change must have been ~2006

Result: No dhcp client in stage3 (thanks Wolf31o2)

And it took a long time to be properly fixed

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

[Mike Gilbert]

On Wed, Dec 4, 2013 at 6:45 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 12/05/2013 05:30 AM, Mike Gilbert wrote:
>> On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs <williamh@gentoo.org> wrote:
>>> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
>>>> seems like a virtual that wouldn't do anything useful except pull in
>>>> random package(s) a la binary-distribution style
>>>
>>> What about the stages? Don't we need some form of net support in
>>> stage 3?
>>>
>>
>> That's debatable. For a typical install, the user has to install other
>> basic stuff like a boot loader, kernel, etc. So having them also
>> select a network config framework seems logical.
>>
>> Is there a use case for a stage3 in which installing netifrc by hand
>> is impractical?
>>
> Well ...
>
> I remember filing a bug quite a while ago because we didn't have a dhcp
> client included anymore. This made installs quite annoying because
> before it was stage3, kernel, bootloader, go!
>
> And now it was go ... stop ... reboot ... install dhcp client ...
> grremblwrrxrmkrxtlmrrrg .... reboot
>
> That extra step of whining was loud enough to have openrc fixed to be
> able to use busybox udhcp, so that "out of the box" most network worked.
>
> ... and now people are trying to do the same again.
>
> I would STRONGLY recommend having a working network setup included in
> stage3, so that compared to now nothing changes.
>
>

Yeah, after some further thought, I'm inclined to agree.

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]

On Wed, Dec 04, 2013 at 07:17:45PM -0500, Mike Gilbert wrote:
> On Wed, Dec 4, 2013 at 6:45 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> > On 12/05/2013 05:30 AM, Mike Gilbert wrote:
> >> On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs <williamh@gentoo.org> wrote:
> >>> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
> >>>> seems like a virtual that wouldn't do anything useful except pull in
> >>>> random package(s) a la binary-distribution style
> >>>
> >>> What about the stages? Don't we need some form of net support in
> >>> stage 3?
> >>>
> >>
> >> That's debatable. For a typical install, the user has to install other
> >> basic stuff like a boot loader, kernel, etc. So having them also
> >> select a network config framework seems logical.
> >>
> >> Is there a use case for a stage3 in which installing netifrc by hand
> >> is impractical?
> >>
> > Well ...
> >
> > I remember filing a bug quite a while ago because we didn't have a dhcp
> > client included anymore. This made installs quite annoying because
> > before it was stage3, kernel, bootloader, go!
> >
> > And now it was go ... stop ... reboot ... install dhcp client ...
> > grremblwrrxrmkrxtlmrrrg .... reboot
> >
> > That extra step of whining was loud enough to have openrc fixed to be
> > able to use busybox udhcp, so that "out of the box" most network worked.
> >
> > ... and now people are trying to do the same again.
> >
> > I would STRONGLY recommend having a working network setup included in
> > stage3, so that compared to now nothing changes.
> >
> >
> 
> Yeah, after some further thought, I'm inclined to agree.

I think we would be safe as long as we make sure to document in the
handbook that users must choose a network manager. We could recommend
netifrc by default for now until we can document how to set up the
others.

Once all of this hits stable I want to work with releng to get them
to use standalone dhcpcd on the LiveCD.

What do you think?

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/12/13 08:56 PM, William Hubbs wrote:
> On Wed, Dec 04, 2013 at 07:17:45PM -0500, Mike Gilbert wrote:
>> On Wed, Dec 4, 2013 at 6:45 PM, Patrick Lauer
>> <patrick@gentoo.org> wrote:
>>> On 12/05/2013 05:30 AM, Mike Gilbert wrote:
>>>> On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs
>>>> <williamh@gentoo.org> wrote:
>>>>> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen
>>>>> wrote:
>>>>>> seems like a virtual that wouldn't do anything useful
>>>>>> except pull in random package(s) a la binary-distribution
>>>>>> style
>>>>> 
>>>>> What about the stages? Don't we need some form of net
>>>>> support in stage 3?
>>>>> 
>>>> 
>>>> That's debatable. For a typical install, the user has to
>>>> install other basic stuff like a boot loader, kernel, etc. So
>>>> having them also select a network config framework seems
>>>> logical.
>>>> 
>>>> Is there a use case for a stage3 in which installing netifrc
>>>> by hand is impractical?
>>>> 
>>> Well ...
>>> 
>>> I remember filing a bug quite a while ago because we didn't
>>> have a dhcp client included anymore. This made installs quite
>>> annoying because before it was stage3, kernel, bootloader, go!
>>> 
>>> And now it was go ... stop ... reboot ... install dhcp client
>>> ... grremblwrrxrmkrxtlmrrrg .... reboot
>>> 
>>> That extra step of whining was loud enough to have openrc fixed
>>> to be able to use busybox udhcp, so that "out of the box" most
>>> network worked.
>>> 
>>> ... and now people are trying to do the same again.
>>> 
>>> I would STRONGLY recommend having a working network setup
>>> included in stage3, so that compared to now nothing changes.
>>> 
>>> 
>> 
>> Yeah, after some further thought, I'm inclined to agree.
> 
> I think we would be safe as long as we make sure to document in
> the handbook that users must choose a network manager. We could
> recommend netifrc by default for now until we can document how to
> set up the others.
> 
> Once all of this hits stable I want to work with releng to get
> them to use standalone dhcpcd on the LiveCD.
> 
> What do you think?

If the stage3 could include a dhcp client and (ideally imo) netifrc,
even though they aren't a part of @system, that would help prevent the
"stuff missing, damnit, have to reboot back to livecd" cycle.  Since
it isn't part of @world we would still need the documentation and
instructions for someone to explicitly choose a network provider,
otherwise they'll be bitten with it disappearing via --depclean.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlKh7I8ACgkQ2ugaI38ACPBeDgD9GV+Mk4mbHLRRzqAfXfqei5Ci
JRLuN0I1e1nW08DT93oA/0FlNasD9KlGNCUwG6JrJhuEQs2H8Damau7KsWO2GibN
=500q
-----END PGP SIGNATURE-----

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

[Ben Kohler]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

On Fri, Dec 6, 2013 at 9:26 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
>
>
> If the stage3 could include a dhcp client and (ideally imo) netifrc,
> even though they aren't a part of @system, that would help prevent the
> "stuff missing, damnit, have to reboot back to livecd" cycle.  Since
> it isn't part of @world we would still need the documentation and
> instructions for someone to explicitly choose a network provider,
> otherwise they'll be bitten with it disappearing via --depclean.
>
> The user can still bring up networking via ifconfig or udhcpc if he
happens to miss the handbook section on networking.  If the user skips
parts of the handbook, things may not work quite right... but the manual
workaround is so trivial anyway, this is really a non-issue.  Just make it
clear that "emerge netifrc" is needed to use net.* scripts, and mention
some alternatives.  A news item would be a good idea to warn veteran
"haven't used the handbook in years" people.

-Ben

[-- Attachment #2: Type: text/html, Size: 1423 bytes --]

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

[Alan McKinnon]

On 05/12/2013 01:45, Patrick Lauer wrote:
> On 12/05/2013 05:30 AM, Mike Gilbert wrote:
>> On Wed, Dec 4, 2013 at 4:25 PM, William Hubbs <williamh@gentoo.org> wrote:
>>> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
>>>> seems like a virtual that wouldn't do anything useful except pull in
>>>> random package(s) a la binary-distribution style
>>>
>>> What about the stages? Don't we need some form of net support in
>>> stage 3?
>>>
>>
>> That's debatable. For a typical install, the user has to install other
>> basic stuff like a boot loader, kernel, etc. So having them also
>> select a network config framework seems logical.
>>
>> Is there a use case for a stage3 in which installing netifrc by hand
>> is impractical?
>>
> Well ...
> 
> I remember filing a bug quite a while ago because we didn't have a dhcp
> client included anymore. This made installs quite annoying because
> before it was stage3, kernel, bootloader, go!
> 
> And now it was go ... stop ... reboot ... install dhcp client ...
> grremblwrrxrmkrxtlmrrrg .... reboot
> 
> That extra step of whining was loud enough to have openrc fixed to be
> able to use busybox udhcp, so that "out of the box" most network worked.
> 
> ... and now people are trying to do the same again.
> 
> I would STRONGLY recommend having a working network setup included in
> stage3, so that compared to now nothing changes.


In this day and age not having a network-capable install out the box is
silly. The first major action after unpacking the tarball is going to be
adding new packages and doing updates, the source code for which is on
the network.

Network is only slightly less necessary than disk drivers - almost
everyone is going to need it. So just ship the thing that the majority
will need, for the few that have a valid case to not need networking
after install, it's a simple matter for them to disable it.

The default install doesn't need to have a network provider with all the
bells and whistles, netifrc is perfectly adequate (especially if dhcp is
enabled as it always was for years)


-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Rich Freeman]

On Thu, Dec 5, 2013 at 2:39 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> In this day and age not having a network-capable install out the box is
> silly. The first major action after unpacking the tarball is going to be
> adding new packages and doing updates, the source code for which is on
> the network.

A network manager isn't needed to use a network - only to set one up.
The network is already set up when you unpack the tarball and chroot
into it.

You could just as easily argue that in this day and age not having a
kernel install out-of-the-box is silly, and yet that is exactly how we
supply the stage3.  There isn't an obvious choice for a kernel, so we
don't make it for the user.  We could just stick gentoo-sources in
there and let the user unmerge it and merge something else, I suppose.

We don't ship a working pulseaudio either, since many don't use it,
and alternatives exist.

I guess the main virtue of the openrc network managers is that they're
disabled by default, and at the moment I don't think they collide with
anything else.  That being the case, their inclusion isn't as
impactful as it would be for other packages.

Rich

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

[Samuli Suominen]

On 04/12/13 23:25, William Hubbs wrote:
> On Wed, Dec 04, 2013 at 06:46:36PM +0200, Samuli Suominen wrote:
>> seems like a virtual that wouldn't do anything useful except pull in
>> random package(s) a la binary-distribution style
> What about the stages? Don't we need some form of net support in
> stage 3?
>
> William
>

nope.   it would fall into same category with 'emerge dhcpcd' like in
the handbook.

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/03/2013 04:11 PM, William Hubbs wrote:
> 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?
> 
> 	William
> 

I see two issues here. Both are rather trivial to solve imho.

1.) If we are going to stuff this into @system then we probably want a
USE=nonet flag to allow users to not pull anything in if they really
don't want it.

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.


Just as a side note, after reading the thread up through this point, I'm
terrified of the individuals who wish to remove networking support from
stage3 entirely.  If anyone wants to push that idea then that needs to
be addressed by the council.  Period.  Such a major change is going to
cause a holy war, and myself and others will actively revert any change
which removes net from stage3 under the guise of "critical breakage"
unless there is council direction that says we are no longer including
net support in the stage3s.

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.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSoreIAAoJEKXdFCfdEflKKdIP/3fhppSUlXv60Ah1T1AECisC
ssISEgKx5RsW608NnfpaYpmXdLgpDW5aSZDqXsIIBUP4/E4gTdP/gJqP36A4wsM3
HOwckcbsbTwtMquVngnpJ/stSCdzN/67lUelVxQwE+e90kZjihJnzRk1jhr8Ejxm
6J7G4m71T/OeE4ldZ/HeCliFpT5gPJNA1JVTcZoXkNIrggbvHFI8aQnLEDF6lX2E
1WjiW3Vq4Quz5cLNi1rE8di+HMRVZQVC4M1m6TtzyQP2Zzic3pwR4cGM/F2hLTvL
EhQeZQpIix8qzd0MTonCEhOGpMcWBEBvI8+8gZNp9xeZ6ibBY8fRheT+OlVCXpVF
+m07KABgiMRqQQHsMOgJRNSl9hocIjDEUQaxmvvTqXIDeElEEy7MOKdST7okWtrb
bI5GNBrYc0JPEroi0uE6pvI7W8g9vS1y6hBQcpIQXxgJCccVx2TTUhF65on6tzNx
NTqph2WAWtrPS3oIjGfbbOk4bujSP/OaOBN2HAuimZ4PW2hbOoW0mtSNUItGWXGY
o+8OnIrday7aWloT6CLByqWNLqfgTWFEJvBzVd5vuLAlkVUWCQgGx0XWgeEJHEeQ
zAxX9rcn6z4ACB9v+Xs96lkxHcjNPrHcjRfaQYDlm/OxliDe3FrryfrRtxjGKbws
ZQYvnajkTjK4UYEEF8zf
=eY8S
-----END PGP SIGNATURE-----

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

[Rich Freeman]

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

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/07/2013 07:42 AM, Rich Freeman wrote:
>> 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.

Choice is fine, I love choice, but to have a user unpack a stage tarball
and find no way at all to handle their networking.... that's just ugly.
 I mean we could just have dhcpcd in @system and let people figure it
out from there (wouldn't be my first choice but it would work) but I
would say it is rare enough to not need net that removing all networking
options from stage3 is near suicidal.

I can do all kinds of amazing things on a system without an MTA.  But if
I have no net I can't even install net....

- -Zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSoy8/AAoJEKXdFCfdEflK+a4P/056EtlWAr12QT7HdeoLhL2d
+OQ2P53jd+fChB5NlrxKLot/+hvf+0PuJXkJU76hDBJ+1g9UkjSsYy1YGhPQ0rTU
d5Ugqn0ZWIrON5QLx4CKH9XUjuN0jW2IlXXGpQApCrsBKv28vRM/oTi9jvC27IAP
IdvD7QBUyN4L+K9z8cOWa1jckZahCrNrsWzgfoCDyJfDep+qeRXe0EbriHvXyfBm
iT295qLUWjR1577bPRNwe7/H0tAe+yoexcJa/M3U4KiSX5qxlqwxr0aN6lFRNevj
1hB7xONTLa08sjx/NxzTID0zMoiZSlmkBLk/V3rj6uYkaFsjo89NvAfNhKZXerWf
sLG/ivFKLFdeghZe6ItTDxIToTm0EnMPI8by8ZRD/xZ6MMre1QnDhODrVx0uMPl2
DRcoe3wItI1ZlX33I+ktF7iP5QZUvL59k15jBCoSnmU8mxSyM+REB/5O7IgLJvGI
+SMoQB14+WwE/jDvz3HVqCifkwU2GDg3t3NT7lUq8yinovGjISufSuDdPY/croFl
kgCLJ5JlEkHkv3EQPyce0ad6zkf6gpc4rWKv3hxxpSNDkKQ7CJyd51zF9S0bWztx
4KjAB5GJRNVxCEcWuh6F8/cSlh3yGTxrbJRh8M3SL1l3JPAo+xcK5nFwZ9Wz/ubk
3jpHrLIuH6+71NPsbZc/
=8QVC
-----END PGP SIGNATURE-----

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

[Rich Freeman]

On Sat, Dec 7, 2013 at 9:22 AM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> Choice is fine, I love choice, but to have a user unpack a stage tarball
> and find no way at all to handle their networking.... that's just ugly.
>  I mean we could just have dhcpcd in @system and let people figure it
> out from there (wouldn't be my first choice but it would work) but I
> would say it is rare enough to not need net that removing all networking
> options from stage3 is near suicidal.
>
> I can do all kinds of amazing things on a system without an MTA.  But if
> I have no net I can't even install net....

If you have no bootloader you can't install a bootloader.  If you have
no kernel...

You don't need dhcpcd in your stage3 to chroot into your stage3 - the
network is established by the install CD.  You just lose the network
if you reboot before you've installed a network manager, in which case
you need to reboot from the CD, chroot, install the network manager,
and then reboot again.  It is no different than forgetting to install
other popular and critical packages like lilo or pf-sources, and I
don't see anybody suggesting that those should be on the stage3.

I don't use WiFi so it isn't that big a deal for me personally, but I
can see the argument in making the installation of a network manager
part of the handbook.  We already have a whole page on how to set up
the network for the install CD itself assuming dhcp doesn't just work.

Rich

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

[Peter Stuge]

Rich Freeman wrote:
> I can see the argument in making the installation of a network manager
> part of the handbook.  We already have a whole page on how to set up
> the network for the install CD itself assuming dhcp doesn't just work.

I think the handbook should at a minimum have a recipe for
replicating the same network manager setup as is on the CD.


//Peter

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On Sun, Dec 08, 2013 at 03:34:59AM +0100, Peter Stuge wrote:
> Rich Freeman wrote:
> > I can see the argument in making the installation of a network manager
> > part of the handbook.  We already have a whole page on how to set up
> > the network for the install CD itself assuming dhcp doesn't just work.
> 
> I think the handbook should at a minimum have a recipe for
> replicating the same network manager setup as is on the CD.

Agreed, and I'll be talking to Jorge in releng about this, because I
may recommend switching to dhcpcd on the live cd after all of this hits
stable.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Jorge Manuel B. S. Vicetto]

On Sat, 7 Dec 2013, Rich Freeman wrote:

> On Sat, Dec 7, 2013 at 12:52 AM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:

<snip>

>> 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.

I disagree with you about this - stage3 and @system are not the same.
The purpose of a stage3 is to provide the minimum "sane" environment to do 
an install. We provide some packages because of "convenience".
So even though someone might not want to connect remotely,  there's no 
valid reason to drop openssh from a stage3. Just like we'll  keep 
providing nano and less in the stages - they may not be needed, but 
it makes sense to provide them.

> 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.

There's an open bug about this - 
https://bugs.gentoo.org/show_bug.cgi?id=393445

Some of the previous comments are based with this bug in mind.

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

[Jeroen Roovers]

On Sat, 7 Dec 2013 07:42:48 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> 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

Since we do want net-misc/rsync, having net-misc/openssh for --rsh=ssh
usage is probably unavoidable in a stage3. Also, scp.


     jer

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

[Peter Stuge]

Rich Freeman wrote:
> 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.

+1


Rick Zero_Chaos Farina wrote:
> Choice is fine, I love choice, but to have a user unpack a stage tarball
> and find no way at all to handle their networking.... that's just ugly.

The system where you unpack the stage likely already handles networking.


> I would say it is rare enough to not need net that removing all
> networking options from stage3 is near suicidal.

I disagree. Not everything is connected. I also like that there's no
syslog and no cron in stage3.


> I can do all kinds of amazing things on a system without an MTA. 
> But if I have no net I can't even install net....

If you need net then make sure to install the manager you prefer
during installation.

I think that makes a lot of sense.


//Peter

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

On Sat, Dec 07, 2013 at 12:52:08AM -0500, Rick "Zero_Chaos" Farina wrote:
> 1.) If we are going to stuff this into @system then we probably want a
> USE=nonet flag to allow users to not pull anything in if they really
> don't want it.

We don't have to put this in @system at all. We could just have a
virtual/network-manager, like we have virtual/cron, virtual/logger,
virtual/mta, etc. None of these are installed by default; you have to
choose one as part of your installation process. The more I read this
thread, the more I agree with this approach; let the user make the
choice as part of the installation process.

> Just as a side note, after reading the thread up through this point, I'm
> terrified of the individuals who wish to remove networking support from
> stage3 entirely.  If anyone wants to push that idea then that needs to
> be addressed by the council.  Period.  Such a major change is going to
> cause a holy war, and myself and others will actively revert any change
> which removes net from stage3 under the guise of "critical breakage"
> unless there is council direction that says we are no longer including
> net support in the stage3s.

I am in agreement with Rich and Peter. This isn't a matter of breaking
the stages; it is a matter of us getting out of the way and letting the
users pick the network stack they want. We do this for the kernel, boot
loader, etc, so I don't understand why you feel we need council
direction to make a similar change for the network manager.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/08/2013 05:25 PM, William Hubbs wrote:
> On Sat, Dec 07, 2013 at 12:52:08AM -0500, Rick "Zero_Chaos" Farina wrote:
>> 1.) If we are going to stuff this into @system then we probably want a
>> USE=nonet flag to allow users to not pull anything in if they really
>> don't want it.
> 
> We don't have to put this in @system at all. We could just have a
> virtual/network-manager, like we have virtual/cron, virtual/logger,
> virtual/mta, etc. None of these are installed by default; you have to
> choose one as part of your installation process. The more I read this
> thread, the more I agree with this approach; let the user make the
> choice as part of the installation process.
> 
>> Just as a side note, after reading the thread up through this point, I'm
>> terrified of the individuals who wish to remove networking support from
>> stage3 entirely.  If anyone wants to push that idea then that needs to
>> be addressed by the council.  Period.  Such a major change is going to
>> cause a holy war, and myself and others will actively revert any change
>> which removes net from stage3 under the guise of "critical breakage"
>> unless there is council direction that says we are no longer including
>> net support in the stage3s.
> 
> I am in agreement with Rich and Peter. This isn't a matter of breaking
> the stages; it is a matter of us getting out of the way and letting the
> users pick the network stack they want. We do this for the kernel, boot
> loader, etc, so I don't understand why you feel we need council
> direction to make a similar change for the network manager.


I am softening a bit, but I'm really concerned that the stages all of a
sudden not having net is going to be an issue for people.  Maybe I'm
mistaken, but it is hard for me to imagine that moving to a stage3 with
no net anything is an improvement.  I suppose you can't download a
stage3 without net, so you should typically be able to just chroot in...
I can honestly say most of the time when setup my arm systems I'm
unpacking the arm stage3 on an amd64 and then booting the arm device
with the base stage3 and fixing things from there.  I suppose it is
possible to use qemu to install things, as long as I don't mind
pretending it's 1999 due to the slow emulation speeds...  Yeah, I really
don't see an improvement here.  It works fine for "I'm an amd64 user and
that's all I'll ever use" but when you start talking about smaller
arches it really starts to become a hassle imho.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSpdiZAAoJEKXdFCfdEflKQ4kP/1RRWpXE2rN0Y74c9GW24l7W
G3oFLQABgFd+8Osq+bKhFaY6uQ0pmV5Cz+a1cj9fa0LnyCumiEL+k+Z6LnuCdqat
rZCQugvP3shvcWYVxKPjR6FEfXjGE8cPm+C32vV9oo0sDfAwjcflYFrXoeTTF07E
Tp/r318TllEQ50KdeLzD9uBBxePFFClygYvppVEWfNUbSSWiB+rkvN2dF6LDCLBi
lpYsozOEpRAoyCQYePQ/eo6iRHmWu39iq4qARek3UXKvZk6h+4qr4/EVtrG3v0A1
0d9mmMAySDQwLPR+CrpN19MD+4qgFjPPIVmdfG5sSU4CM3jf4elap55X6aircWzf
m1CsIPxaBmOicNUNr3OMPn1vr/Sufd1jgC6wwaZRp77POqlpzEqKM9y6JCkF7xy8
2z8Enl7TvwIzre4f7qK7u/HXSvaUX8F97TI09XkzuMlrk69WMMzsmxLtngZy0I96
egKCsGsKKF8k0biolM0hav4R7RPTVdK+/3U6SJwF+QSTZay/dyQpG4543reNuarr
y8uoeIrXA03RE71BRBeRArgBeR7PpoUld59IP+XzCdCWb5GqZYAuE7zmfFvvctnk
Z+M3KhwSzyqA8Pie6YTTlTyBl7uyr6Hqs0vfiP14ctVKtIkiayE8Q2XjW9i+zODA
EjwJy84Q3uQXjU2kxIDU
=WYkG
-----END PGP SIGNATURE-----

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

[Rich Freeman]

On Mon, Dec 9, 2013 at 9:50 AM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> I can honestly say most of the time when setup my arm systems I'm
> unpacking the arm stage3 on an amd64 and then booting the arm device
> with the base stage3 and fixing things from there.  I suppose it is
> possible to use qemu to install things, as long as I don't mind
> pretending it's 1999 due to the slow emulation speeds...  Yeah, I really
> don't see an improvement here.  It works fine for "I'm an amd64 user and
> that's all I'll ever use" but when you start talking about smaller
> arches it really starts to become a hassle imho.

Ok, now the concern is becoming more clear.  You're intending to boot
directly to the stage3 and not chroot into it, and so you want the
stage3 to be a fully-functional userspace, though you don't actually
need it to contain a kernel/bootloader.

How do you even log into the stage3?  Do we not disable the root
password by default?

Can you boot off of the minimal install image instead?  Not sure if we
have one of those for ARM.  Actually, any boot image that sets up a
network and supports chroot would work fine for your purposes.  I do
realize that many (all?) ARM platforms don't have a flexible
bootloader like x86 typically does - so I'll let you speak to what
makes sense here.

Following the handbook, the network is established by the boot CD and
all you do before chrooting is copy over your resolv.conf.  In that
environment there is no need to have a networking system pre-installed
on the stage3.

Oh, and if I'm not mistaken the stage3 is based on the system set
which is established by the profile, so if it made sense to keep
networking around for ARM that would be an option.

Rich

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

[Steev Klimaszewski]

On Mon, 2013-12-09 at 10:28 -0500, Rich Freeman wrote:
> Ok, now the concern is becoming more clear.  You're intending to boot
> directly to the stage3 and not chroot into it, and so you want the
> stage3 to be a fully-functional userspace, though you don't actually
> need it to contain a kernel/bootloader.
> 

A stage3 is pretty much fully functional if you just create net.ethX and
ln it in the default runlevel. (It will currently use busybox's udhcpc
for dhcp client)

> How do you even log into the stage3?  Do we not disable the root
> password by default?

You can easily echo a password into /mnt/gentoo/etc/shadow - see code
listing 5.4 on
http://dev.gentoo.org/~armin76/arm/beagleboneblack/install.xml

> 
> Can you boot off of the minimal install image instead?  Not sure if we
> have one of those for ARM.  Actually, any boot image that sets up a
> network and supports chroot would work fine for your purposes.  I do
> realize that many (all?) ARM platforms don't have a flexible
> bootloader like x86 typically does - so I'll let you speak to what
> makes sense here.

We don't really have any minimal boot images for ARM as each device is
different.  Some devices have a u-boot that will boot an sdcard, some
require you to put u-boot on the sdcard, some require a button press
while having u-boot on the sdcard... so on and so forth.  I'm not sure
we really want to put out an image for each card (though it is something
I'd like to discuss if the arm@ team would freaking reply to the thread
on arm@ about having a freaking team meeting) 

> 
> Following the handbook, the network is established by the boot CD and
> all you do before chrooting is copy over your resolv.conf.  In that
> environment there is no need to have a networking system pre-installed
> on the stage3.
> 

You can do this with a qemu chroot on an amd64/x86 machine - but as ZC
mentioned, it's slow - really slow - qemu emulates an arm processor
running about 200mhz slow, and really NOT ideal at all.  I currently
suffer through it to build wpa_supplicant as a lot of my arm devices use
wifi, but it really sucks.  Even building on an rpi is faster than
through qemu.

> Oh, and if I'm not mistaken the stage3 is based on the system set
> which is established by the profile, so if it made sense to keep
> networking around for ARM that would be an option.
> 
> Rich
> 

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/09/2013 10:28 AM, Rich Freeman wrote:
> On Mon, Dec 9, 2013 at 9:50 AM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
>> I can honestly say most of the time when setup my arm systems I'm
>> unpacking the arm stage3 on an amd64 and then booting the arm device
>> with the base stage3 and fixing things from there.  I suppose it is
>> possible to use qemu to install things, as long as I don't mind
>> pretending it's 1999 due to the slow emulation speeds...  Yeah, I really
>> don't see an improvement here.  It works fine for "I'm an amd64 user and
>> that's all I'll ever use" but when you start talking about smaller
>> arches it really starts to become a hassle imho.
> 
> Ok, now the concern is becoming more clear.  You're intending to boot
> directly to the stage3 and not chroot into it, and so you want the
> stage3 to be a fully-functional userspace, though you don't actually
> need it to contain a kernel/bootloader.

Correct
> 
> How do you even log into the stage3?  Do we not disable the root
> password by default?

No, we don't disable it.  It's trivial to set without chrooting (steev
has details in his response and that isn't he point of this thread)
> 
> Can you boot off of the minimal install image instead?  Not sure if we
> have one of those for ARM.  Actually, any boot image that sets up a
> network and supports chroot would work fine for your purposes.  I do
> realize that many (all?) ARM platforms don't have a flexible
> bootloader like x86 typically does - so I'll let you speak to what
> makes sense here.

Sadly no, again covered by steev in his response we don't off anything
bootable for arm at all.
> 
> Following the handbook, the network is established by the boot CD and
> all you do before chrooting is copy over your resolv.conf.  In that
> environment there is no need to have a networking system pre-installed
> on the stage3.

Well hold on there... the handbook doesn't mention anything about
emerging your choice of network manager just yet, and when everything
including dhcpcd isn't in the stage3 you will need to do more than copy
resolv.conf (which honestly I never do anyway) or it won't work very well.
> 
> Oh, and if I'm not mistaken the stage3 is based on the system set
> which is established by the profile, so if it made sense to keep
> networking around for ARM that would be an option.
> 

I grant this is an option, but what about guys like steev?  He has a
large stack of arm devices and like 1 amd64 box.  What if he wants to
put a stage3 on a disk for his amd64 box from his arm box?  I'd love to
see him emulate an amd64 from his arm to install dhcpcd.

Now granted, that's being a little pedantic, as he could probably use
one of the gentoo isos available to boot instead, but the point is we
are removing software that gives the user a choice under the guise of
giving the user a choice.

I really don't like the idea of having no networking in the stage3 by
default, however, I'm becoming more open minded on what qualifies as
networking.  What I'm wrestling with is this, what if I want to slap a
stage3 on a device and then access it from the network?  Almost nothing
in my place has a monitor (amd64 and arm alike) and I use one of my two
laptops to talk to everything else.  Say I want to rebuild a headless
machine, what am I supposed to do?  Unpack a stage3, install some
network manager manually (netifrc for me) and then boot?  Granted, we
already have to do this for any device which is wifi only as
wpa_supplicant isn't in the stage3, but to remove this ability from
wired devices as well.... I'm torn, I really don't think it's a great
idea.  I really feel that while the rest of the world is trying to get
more functionality out of their hardware we are trying to save ~200k and
possibly crippling user experience in the process.

Is removing ~200k really worth the potential downside?  Honestly, if we
are going on the merits of smaller downloads let's argue about using xz
instead of bzip2 for the stages...

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSpiBiAAoJEKXdFCfdEflKuWMP/j7S40wYWxGWbI34Ij2U5dSG
l11wJYdAP0k9bLs4rhDvJG56EaTyBJJYvfDCz+W2XF01MyNcdQfH2BzqEifp0ZOD
kI0x81xzIqpb4YC1KvJXQxStDvs1Nxp3KbCX+Jg2hdkMv4hlHR7NF/g1gUajC8eA
8tKdLcqIz822REqGtShGLYO9cjLaHZhGr/rFlxyK9ReQqj5cCdmEZ1MKN0Kb/DSa
gQf+pmdecXXjCbF3N/5eihcQDrKe2UbXuKM/nNaiVw1ETnI+gjn815ofUNCc3Ynu
jXZC4jse+MVQC6D6i3ZJi6o1VSlrGJmGDDxBSUtBPc7kSgFnaAz3AYC/izeIFtb9
VNQEmrcDjO5qKdZphc5ht2NW7uOBCZbpMoFmSj70cZK+NhJhaJPWqzUNu3mJLCUF
72W89HCC3oTbpPtMVQHz9F3nmzYhH+QfrEXGd96woTyjcsZYwXvY8UDm486gsdsR
aGNJCN34RXQvsLrsJdxJWaHJex5w2UHkBsi5IQkJniD1grq+CModEWiaqfD6Fo/y
WXT1LUr3/1cgsLFU3E5VhgdYl873z2oNUHisWR37XYDN/T3z4AZh1gEYUD30wILw
vctPg/8dJAqcLQUkgqFvtAmlWeY/MPUaqpJLOkwcgN/Zmyw5LNfdyPH//5oT5G++
vYyFkaxsIzPnnAb5omme
=6FAB
-----END PGP SIGNATURE-----

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

[Rich Freeman]

On Mon, Dec 9, 2013 at 2:56 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> I really don't like the idea of having no networking in the stage3 by
> default, however, I'm becoming more open minded on what qualifies as
> networking.  What I'm wrestling with is this, what if I want to slap a
> stage3 on a device and then access it from the network?

Hit your head on the wall because it doesn't contain a kernel?
Stage3s in general aren't functional systems.

> I really feel that while the rest of the world is trying to get
> more functionality out of their hardware we are trying to save ~200k and
> possibly crippling user experience in the process.

The rest of the world would just stick systemd, dbus, pulseaudio,
xorg, an initramfs, every kernel module under the sun, ndiswrapper,
300 windows driver blobs, and a network manager that uses gtk+ to
configure your network on the stage3.  That is how they get more
functionality out of their hardware.  It just isn't the Gentoo way.
:)

>
> Is removing ~200k really worth the potential downside?  Honestly, if we
> are going on the merits of smaller downloads let's argue about using xz
> instead of bzip2 for the stages...

I'm not concerned about space use at all.  I think the main argument
for leaving oldnet on the stage3s is that it doesn't do anything if
you don't symlink it, just like openssh.

If it actually had collisions with other network managers I think
there would be more of a case for removing it.

Rich

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

[Steev Klimaszewski]

On Mon, 2013-12-09 at 20:33 -0500, Rich Freeman wrote:
> On Mon, Dec 9, 2013 at 2:56 PM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
> > I really don't like the idea of having no networking in the stage3 by
> > default, however, I'm becoming more open minded on what qualifies as
> > networking.  What I'm wrestling with is this, what if I want to slap a
> > stage3 on a device and then access it from the network?
> 
> Hit your head on the wall because it doesn't contain a kernel?
> Stage3s in general aren't functional systems.

You're thinking with your x86/amd64 hat on here.  An ARM device can be
booted with the kernel over networking (or even via usb, as is the case
with most Android devices) and rootfs on local storage.  Just because
x86/amd64 doesn't do it, doesn't mean others can't/don't.

What exactly is missing from a stage3 aside from a kernel?  At this
point on most ARM devices, it goes like this:

extract stage3
edit inittab (and if needed) securetty
create net.eth0 & symlink it to the default runlevel, along with
openssh(assuming headless system)
copy your kernel & modules into their proper places (if needed)
put sdcard into arm device, watch it magically boot and work

What you're proposing is:
extract stage3
install qemu (assuming you don't have it yet)
mount dev/proc
chroot
emerge a-network-manager
<go get coffee, have a beer, make a three course meal>
set password (might as well, since you're chrooted)
vim inittab <oh wait, no vim, right, gotta run nano>
nano inittab (and if needed) securetty
exit chroot
unmount dev/proc
copy kernel & momdules to their proper places
put sdcard into arm device, watch it magically boot and work

Why exactly is the latter one better?  the emerge a-network-manager step
would be far faster on the device itself, even the RPi.

I plan to look into the SUSE Qemu fork, as they've supposedly sped it up
immensely (iirc it takes about a week to build gcc according to armin76
for aarch64) but even then, that would be a hack as their patches may or
may not have been sent upstream - and they may be aarch64 specific and
arm could still be slow as balls.

So remember, just because your laptop/desktop can't do awesome stuff,
doesn't mean other devices can't :)

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

[Rich Freeman]

On Tue, Dec 10, 2013 at 5:31 AM, Steev Klimaszewski <steev@gentoo.org> wrote:
> On Mon, 2013-12-09 at 20:33 -0500, Rich Freeman wrote:
> You're thinking with your x86/amd64 hat on here.

Actually, I probably just underquoted.  I am well-aware that there are
issues with ARM, hence my previous suggestion that it might make sense
to vary this by profile.

Let me try my post again, with a bit more quoting:

On Mon, Dec 9, 2013 at 2:56 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> What if he wants to
> put a stage3 on a disk for his amd64 box from his arm box?  I'd love to
> see him emulate an amd64 from his arm to install dhcpcd.
...
> I really don't like the idea of having no networking in the stage3 by
> default, however, I'm becoming more open minded on what qualifies as
> networking.  What I'm wrestling with is this, what if I want to slap a
> stage3 on a device and then access it from the network?
> Almost nothing
> in my place has a monitor (amd64 and arm alike) and I use one of my two
> laptops to talk to everything else.

Hit your head on the wall because it doesn't contain a kernel?
Stage3s in general aren't functional systems.

Insofar as much as he was talking about ARM I get the point.  Insofar
as he is taking about amd64, not so much.  Which he was talking about
in that paragraph I can only guess at.

But as I later said in the same email:

If it actually had collisions with other network managers I think
there would be more of a case for removing it.

After all, we stick openrc and portage (the PM) in the stage3 and you
don't exactly need those in order to run Gentoo...

Rich

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

[Steev Klimaszewski]

On Tue, 2013-12-10 at 06:23 -0500, Rich Freeman wrote:
> On Tue, Dec 10, 2013 at 5:31 AM, Steev Klimaszewski <steev@gentoo.org> wrote:
> > On Mon, 2013-12-09 at 20:33 -0500, Rich Freeman wrote:
> > You're thinking with your x86/amd64 hat on here.
> 
> Actually, I probably just underquoted.  I am well-aware that there are
> issues with ARM, hence my previous suggestion that it might make sense
> to vary this by profile.
> 

Definitely - but then we have to do everything in the profiles, and at
least for ARM, there are currently 6 profiles, and we're considering
introducing a 7th (neon), and we will need to add aarch64, which will be
at least 2 more.  I suppose we could do it in the base arm profile...

> Let me try my post again, with a bit more quoting:
> 
> On Mon, Dec 9, 2013 at 2:56 PM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
> > What if he wants to
> > put a stage3 on a disk for his amd64 box from his arm box?  I'd love to
> > see him emulate an amd64 from his arm to install dhcpcd.
> ...
> > I really don't like the idea of having no networking in the stage3 by
> > default, however, I'm becoming more open minded on what qualifies as
> > networking.  What I'm wrestling with is this, what if I want to slap a
> > stage3 on a device and then access it from the network?
> > Almost nothing
> > in my place has a monitor (amd64 and arm alike) and I use one of my two
> > laptops to talk to everything else.
> 
> Hit your head on the wall because it doesn't contain a kernel?
> Stage3s in general aren't functional systems.
> 
> Insofar as much as he was talking about ARM I get the point.  Insofar
> as he is taking about amd64, not so much.  Which he was talking about
> in that paragraph I can only guess at.
> 
> But as I later said in the same email:
> 
> If it actually had collisions with other network managers I think
> there would be more of a case for removing it.
> 
> After all, we stick openrc and portage (the PM) in the stage3 and you
> don't exactly need those in order to run Gentoo...
> 
> Rich
> 
While you don't need those specifically to run Gentoo, the point of the
stage3 is to have a workable base to start with.  So people are very
much free to yank out openrc and put in, say, systemd, and rip out
portage and add in paludis, if they so choose, and make those available.
And from the traffic I've seen on the systemd list, it looks like they
are adding some sort of networking to systemd itself as well, so we
probably will need a virtual at some point.  My specific point of the
email though, was you saying that a stage3 in general aren't functional
- but they are - they are the very base of a functional system, and you
simply add things on top, or replace things with your preferred methods.
A stage1 or a stage2 isn't particularly functional.

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

[Steven J. Long]

On Tue, Dec 10, 2013, Steev Klimaszewski wrote:
> On Tue, 2013-12-10, Rich Freeman wrote:
> > On Tue, Dec 10, 2013, Steev Klimaszewski wrote:
> > > On Mon, 2013-12-09, Rich Freeman wrote:
> > > You're thinking with your x86/amd64 hat on here.
> > 
> > Actually, I probably just underquoted.  I am well-aware that there are
> > issues with ARM, hence my previous suggestion that it might make sense
> > to vary this by profile.
> > 
> 
> Definitely - but then we have to do everything in the profiles, and at
> least for ARM, there are currently 6 profiles, and we're considering
> introducing a 7th (neon), and we will need to add aarch64, which will be
> at least 2 more.  I suppose we could do it in the base arm profile...

I don't think it would make sense to remove networking from any profile.
Far better to develop a 14 profile using dhcpcd and make that work, without
affecting current users. The virtual could be used to add any higher layer
desired, but would not be required.

> > If it actually had collisions with other network managers I think
> > there would be more of a case for removing it.
> > 
> > After all, we stick openrc and portage (the PM) in the stage3 and you
> > don't exactly need those in order to run Gentoo...

Yup. Which is steev's "functional" point, so you seem to be in agreement.

> While you don't need those specifically to run Gentoo, the point of the
> stage3 is to have a workable base to start with.  So people are very
> much free to yank out openrc and put in, say, systemd, and rip out
> portage and add in paludis, if they so choose, and make those available.
> And from the traffic I've seen on the systemd list, it looks like they
> are adding some sort of networking to systemd itself as well, so we
> probably will need a virtual at some point.  My specific point of the
> email though, was you saying that a stage3 in general aren't functional
> - but they are - they are the very base of a functional system, and you
> simply add things on top, or replace things with your preferred methods.
> A stage1 or a stage2 isn't particularly functional.

Agreed. There's no real point in a stage3 that doesn't support some sort
of networking. It's fine to change over, but again that should be done
with a new profile, not by randomly removing netifrc USE default. The
latter may not be "correct" on a purist level, but it's a darn sight
better than breaking installs, and is only a transitional measure.

The transition is much easier to handle as a profile change, for an
end-user, and the experimental profile facilitates modification of base
stages and working on them, without breaking the current setup.

After all, if someone wants to setup a Gentoo install *without* networking
they are very much doing a specialist thing, and can deal with it
themselves. So I don't think we should give too much time to that
use-case, in terms of implementation effort; staying out of the way when
the user tells us to is all that's required, and that's easy: do nothing,
or in this case, don't force any dependencies on higher-level network
managers, unless required for correct functioning.

Regards,
steveL
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/10/2013 01:46 PM, Steev Klimaszewski wrote:
> On Tue, 2013-12-10 at 06:23 -0500, Rich Freeman wrote:
>> On Tue, Dec 10, 2013 at 5:31 AM, Steev Klimaszewski <steev@gentoo.org> wrote:
>>> On Mon, 2013-12-09 at 20:33 -0500, Rich Freeman wrote:
>>> You're thinking with your x86/amd64 hat on here.
>>
>> Actually, I probably just underquoted.  I am well-aware that there are
>> issues with ARM, hence my previous suggestion that it might make sense
>> to vary this by profile.
>>
> 
> Definitely - but then we have to do everything in the profiles, and at
> least for ARM, there are currently 6 profiles, and we're considering
> introducing a 7th (neon), and we will need to add aarch64, which will be
> at least 2 more.  I suppose we could do it in the base arm profile...
> 
>> Let me try my post again, with a bit more quoting:
>>
>> On Mon, Dec 9, 2013 at 2:56 PM, Rick "Zero_Chaos" Farina
>> <zerochaos@gentoo.org> wrote:
>>> What if he wants to
>>> put a stage3 on a disk for his amd64 box from his arm box?  I'd love to
>>> see him emulate an amd64 from his arm to install dhcpcd.
>> ...
>>> I really don't like the idea of having no networking in the stage3 by
>>> default, however, I'm becoming more open minded on what qualifies as
>>> networking.  What I'm wrestling with is this, what if I want to slap a
>>> stage3 on a device and then access it from the network?
>>> Almost nothing
>>> in my place has a monitor (amd64 and arm alike) and I use one of my two
>>> laptops to talk to everything else.
>>
>> Hit your head on the wall because it doesn't contain a kernel?
>> Stage3s in general aren't functional systems.
>>
>> Insofar as much as he was talking about ARM I get the point.  Insofar
>> as he is taking about amd64, not so much.  Which he was talking about
>> in that paragraph I can only guess at.
>>
>> But as I later said in the same email:
>>
>> If it actually had collisions with other network managers I think
>> there would be more of a case for removing it.
>>
>> After all, we stick openrc and portage (the PM) in the stage3 and you
>> don't exactly need those in order to run Gentoo...
>>
>> Rich
>>
> While you don't need those specifically to run Gentoo, the point of the
> stage3 is to have a workable base to start with.  So people are very
> much free to yank out openrc and put in, say, systemd, and rip out
> portage and add in paludis, if they so choose, and make those available.
> And from the traffic I've seen on the systemd list, it looks like they
> are adding some sort of networking to systemd itself as well, so we
> probably will need a virtual at some point.  My specific point of the
> email though, was you saying that a stage3 in general aren't functional
> - but they are - they are the very base of a functional system, and you
> simply add things on top, or replace things with your preferred methods.
> A stage1 or a stage2 isn't particularly functional.
> 

To be exact here, stage2 IS what is needed to bootstrap. stage3 is what
is needed to have a semi-functional system.  If everyone wants a
*MINIMAL* tarball to start from I'm sure releng can put the stage2's
onto the mirror so that people will leave my functional stage3 along and
quit saying what they don't need.

If you want nothing which isn't needed past the bootstrapping of the
toolchain then stage2 is what you want.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSr3/KAAoJEKXdFCfdEflKWNkQAK0vLGjGN96EUimf8kXQxNYJ
GSA9lOIGbdoaf0oG1917m56/4RoZfWJ4SH+5ylajIf0wBrZB+mrL+740msnq+XNz
xUpFZjB/cliYprv5WxpH+HjsvD8/vOvDZ97nj4IfPwoT33ntu4aTeHbKQ9uCNkA4
FD/LJ+lZliPOIaeji0Gzmnp/B16s09W+Aa1F5gZ7TNCnNA3uchQPAZarT4BmThQB
H88/Vo7s5SxfBTTuSv54lLdFPesTz65jTzBPIA35nggrCZHiCrc73zQ+gfiMDUuK
q9eyA1MkvjX7NNdgL4hSFARUw+wYiq2mCaBc+rbG8x5xATR4P+U/NU9kU/ZbfcUQ
tVUIQ6txuGhD3vyvxUYN4mWmuRyl9s9z9sUvVmGD7JRt9lCioLwN/IDz0CQpCVtD
L+e68xrfcNR1vsc9isfo1wV5y9eVgenO8etq7xxQinXW8iEkSyPSablKcTrIRh3f
U5b67wkikXP/Fhtvha6XGr/PYGCK2KTxc+Vo0a2r6aenJSk9WVDKlBcmIt92MKYh
CZvzz1rNgtrbSvwY8f4YxXo4XGIUUYeQbj+DksCfVPaYXjvb75rC/axuYSMyGM+D
5WFDUoGdSOrXAI4hgvDLSp8aQvJ1mRq/8Uw7iR+KTxAEYXaIW3NFRhRGaz4iSe2I
Amni8AvCnKWaEt5w57Ox
=RxMv
-----END PGP SIGNATURE-----

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

My issue with what we are currently doing is not whether we have a
default network provider in the stages or not, but it is just that the
netifrc use flag on OpenRC is bogus. OpenRC doesn't need netifrc for any
reason.

I think if we are going to have a default network manager in the
stages we should do it by adding a virtual/network-manager then adding
that to @system.

I couldn't find dhcpcd in @system, so I don't think it is in the
stages.

Dhcpcd by default wants to be a standalone network manager, so I also
think it is reasonable that if you want to use dhcpcd per interface
along with netifrc you should have to make sure both of them (dhcpcd and
netifrc) are in @world. You would just have to run
emerge --noreplace netifrc dhcpcd.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Jorge Manuel B. S. Vicetto]

On Tue, 10 Dec 2013, William Hubbs wrote:

> My issue with what we are currently doing is not whether we have a
> default network provider in the stages or not, but it is just that the
> netifrc use flag on OpenRC is bogus. OpenRC doesn't need netifrc for any
> reason.

William,

the "push" for the use flag was to ensure that users would keep the 
existing networking functionaility and more importantly their network 
configuration. Without it, portage would "happily" clean /etc/conf.d/net - 
something not desirable by most.

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

On Sat, Dec 14, 2013 at 05:56:33AM +0000, Jorge Manuel B. S. Vicetto wrote:
> On Tue, 10 Dec 2013, William Hubbs wrote:
> 
> > My issue with what we are currently doing is not whether we have a
> > default network provider in the stages or not, but it is just that the
> > netifrc use flag on OpenRC is bogus. OpenRC doesn't need netifrc for any
> > reason.
> 
> William,
> 
> the "push" for the use flag was to ensure that users would keep the 
> existing networking functionaility and more importantly their network 
> configuration. Without it, portage would "happily" clean /etc/conf.d/net - 
> something not desirable by most.

Hi Jorge,

Portage will not clean /etc/conf.d/net, and this is not related to the
use flag. That is handled by the block starting at line 212 in
openrc-0.12.4.ebuild. I had to modify the file so portage
wouldn't remove it.

The push for the use flag was because people didn't think it was enough
for me to put out a news item telling them that they should emerge
netifrc if they wanted to continue using it once this version of OpenRC
was installed.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Jorge Manuel B. S. Vicetto]

On Sat, 14 Dec 2013, William Hubbs wrote:

> On Sat, Dec 14, 2013 at 05:56:33AM +0000, Jorge Manuel B. S. Vicetto wrote:
>> On Tue, 10 Dec 2013, William Hubbs wrote:
>>
>>> My issue with what we are currently doing is not whether we have a
>>> default network provider in the stages or not, but it is just that the
>>> netifrc use flag on OpenRC is bogus. OpenRC doesn't need netifrc for any
>>> reason.
>>
>> William,
>>
>> the "push" for the use flag was to ensure that users would keep the
>> existing networking functionaility and more importantly their network
>> configuration. Without it, portage would "happily" clean /etc/conf.d/net -
>> something not desirable by most.
>
> Hi Jorge,
>
> Portage will not clean /etc/conf.d/net, and this is not related to the
> use flag. That is handled by the block starting at line 212 in
> openrc-0.12.4.ebuild. I had to modify the file so portage
> wouldn't remove it.

Ah, that's good to know.
I mentioned /etc/conf.d/net as you know I lost it on a production box when 
the new openrc with netifrc was initially released. It's good to know that 
was fixed on a different way.

> The push for the use flag was because people didn't think it was enough
> for me to put out a news item telling them that they should emerge
> netifrc if they wanted to continue using it once this version of OpenRC
> was installed.

OK, I see what you mean.
To be clear, I'm not ready to have a stage3 without netifrc. If / when we 
update catalyst so that the new stage3 is the sum of @system and 
additional packages, we can move netifrc to that list.

> William

Jorge

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

[William Hubbs]

[-- Attachment #1.1: Type: text/plain, Size: 1182 bytes --]

On Sat, Dec 14, 2013 at 08:47:01PM +0000, Jorge Manuel B. S. Vicetto wrote:
> OK, I see what you mean.
> To be clear, I'm not ready to have a stage3 without netifrc. If / when we 
> update catalyst so that the new stage3 is the sum of @system and 
> additional packages, we can move netifrc to that list.

Actually I'm not even sure how necessary that kind of update is.

I didn't quite follow what the reasoning against my second proposal was.

Once openrc-0.12.4 is stable everywhere it is going to go stable, I want
to add virtual/network-manager to the tree. This would contain a list of
network manager providers.

I think adding it to the tree is good, because we have other virtuals
for multiple packages that perform the same function -- virtual/logger,
virtual/mta, etc.

Once that is done, we could easily add it to @system then I would drop
the netifrc use flag. That would take care of the situation if netifrc
was the default provider.

Then, if you decide to add the function you are talking about to
catalyst, we could look into dropping virtual/network-manager from
@system.

I'll attach the ebuild below so everyone sees it.

William


[-- Attachment #1.2: network-manager-0.ebuild --]
[-- Type: text/plain, Size: 452 bytes --]

# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=5

DESCRIPTION="virtual for network managers"
HOMEPAGE=""
SRC_URI=""

LICENSE=""
SLOT="0"
KEYWORDS="~x86"
IUSE=""

DEPEND=""
RDEPEND=" || (
	net-misc/netifrc
	>=sys-apps/openrc-0.12[newnet]
	<sys-apps/openrc-0.12
	net-misc/badvpn
	net-misc/connman
	net-misc/dhcpcd
	net-misc/netctl
	net-misc/NetworkManager
	net-misc/wicd
	)"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Luis Ressel]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

On Sat, 14 Dec 2013 15:57:04 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Sat, Dec 14, 2013 at 08:47:01PM +0000, Jorge Manuel B. S. Vicetto
> wrote:
> > OK, I see what you mean.
> > To be clear, I'm not ready to have a stage3 without netifrc. If /
> > when we update catalyst so that the new stage3 is the sum of
> > @system and additional packages, we can move netifrc to that list.
> 
> Actually I'm not even sure how necessary that kind of update is.
> 
> I didn't quite follow what the reasoning against my second proposal
> was.
> 
> Once openrc-0.12.4 is stable everywhere it is going to go stable, I
> want to add virtual/network-manager to the tree. This would contain a
> list of network manager providers.
> 
> I think adding it to the tree is good, because we have other virtuals
> for multiple packages that perform the same function --
> virtual/logger, virtual/mta, etc.
> 
> Once that is done, we could easily add it to @system then I would drop
> the netifrc use flag. That would take care of the situation if netifrc
> was the default provider.
> 
> Then, if you decide to add the function you are talking about to
> catalyst, we could look into dropping virtual/network-manager from
> @system.
> 
> I'll attach the ebuild below so everyone sees it.
> 
> William
> 

IMHO this virtual shouldn't be added. It would be a pure meta package
for the user. That case is not directly comparable with virtual/mta:
We've got this for other packages to depend on it, at least that is my
understanding. In a case like this, a handbook entry should suffice.


Luis Ressel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/14/2013 04:57 PM, William Hubbs wrote:
> On Sat, Dec 14, 2013 at 08:47:01PM +0000, Jorge Manuel B. S. Vicetto wrote:
>> OK, I see what you mean.
>> To be clear, I'm not ready to have a stage3 without netifrc. If / when we 
>> update catalyst so that the new stage3 is the sum of @system and 
>> additional packages, we can move netifrc to that list.
> 
> Actually I'm not even sure how necessary that kind of update is.
> 
> I didn't quite follow what the reasoning against my second proposal was.
> 
> Once openrc-0.12.4 is stable everywhere it is going to go stable, I want
> to add virtual/network-manager to the tree. This would contain a list of
> network manager providers.
> 
> I think adding it to the tree is good, because we have other virtuals
> for multiple packages that perform the same function -- virtual/logger,
> virtual/mta, etc.
> 
Excellent idea.  since busybox is in the stage3 and it provides udhcpc
we don't really need dhcpcd or netifrc or even really iproute2.

I have no problem distributing stage2's if everyone wants a crippled
place to start from, but this talk of removing base net scripts makes no
sense to me.  It interferes with nothing. It blocks nothing. It takes
almost no space at all.  There is zero downside to keeping it.  Until
such time as someone tells me an actual downside to having netifrc in
the stage3 I will be reverting any change which removes it as critical
breakage.  You will know when this statement no longer holds when I
specifically state that on this mailing list that I agree, netifrc is a
problem and needs to be removed.  Until then, please, the bike shed is
green.

- -Zero

> Once that is done, we could easily add it to @system then I would drop
> the netifrc use flag. That would take care of the situation if netifrc
> was the default provider.
> 
> Then, if you decide to add the function you are talking about to
> catalyst, we could look into dropping virtual/network-manager from
> @system.
> 
> I'll attach the ebuild below so everyone sees it.
> 
> William
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSr4DpAAoJEKXdFCfdEflKXQgQAJvKeM+avFF381dem8FBpxBC
FVRc7StBNwcaK3k0J3on32HXVAxLGAD+digxD/j1WYS3CUr5xkcM6JOKXAPXOnTr
c6AKrWZpe7UjyqWNY94KVWV+IFXsOUwsaLND+llPVIi5Z+zy0/Cj5qOCQcy28QO2
csdPWykqeyaoD5pPLTXI8wSIm3AyMLryTYkBAiAR1k8CIbSodRK6Rfsb9f7jijTR
8Bm8/zpVZN+wBymzHExDENdNFuVZAr3b8Jz5jVqom+TbiWk2VpeDO2Oo3Pr62q+R
9briW7lE5pyn3GOj3YuRFCb8mUq/r961jCybXbTpm2UE2auh2jSW7yHvnV+yfEcl
tlles7SF+xsb4FysKwNI08nTSGHpVR3j5LVBk21VvNtFtpoaczLhJYqXt29TmfQE
WtUAe6M1c4BlOnJc1J1vsQiEJ/fWrByTXJavW7hxnb513gy2CC2wWY2d/3ROs7g1
iSZQC93W09WPpKu1TbBGd+sh3NdZHZYE9F5HLOKTrpOPOC38PDjJoqiM2h26lwqh
YhA2jpxKvvpyrBgZPigIrlLHDv3n/nx44SRLc37SR2Y/sjVWU3EoI0JQ0LNsXVLP
7RwWyOPdkTsX38JP9JU6nQCQlHkY3NGcaJ3CXxEnCmnzn2XqXhKFd8Rg1Cj2U1ID
AIJJuqOGJZxuwfoCbUhu
=/wy0
-----END PGP SIGNATURE-----

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

[mingdao]

On Tue, Dec 10, 2013 at 08:57:55PM -0600, William Hubbs wrote:
> My issue with what we are currently doing is not whether we have a
> default network provider in the stages or not, but it is just that the
> netifrc use flag on OpenRC is bogus. OpenRC doesn't need netifrc for any
> reason.
> 
> I think if we are going to have a default network manager in the
> stages we should do it by adding a virtual/network-manager then adding
> that to @system.
> 
> I couldn't find dhcpcd in @system, so I don't think it is in the
> stages.
> 
> Dhcpcd by default wants to be a standalone network manager, so I also
> think it is reasonable that if you want to use dhcpcd per interface
> along with netifrc you should have to make sure both of them (dhcpcd and
> netifrc) are in @world. You would just have to run
> emerge --noreplace netifrc dhcpcd.
> 
> William

This entire thread seems to have different terminology used by different
posters, causing me some confusion. So perhaps a few questions:

(1) What is "the new network stack" provided by the newnet USE flag?

(2) Why is dhcpcd referred to as a "network manager" in the same context as
wicd, networkmanager, connman, etc? In the sense that dhcpcd is not sufficient
for security protected wireless alone, as is, say, wicd; and is not a
replacement for true "network manager" apps. DHCP client != network manager
app

(3) Is udhcpc provided by busybox not sufficient in lieu of dhcpcd for stage3? 

Thanks for your explanation(s).

Bruce
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]

You make some good points. I'll answer your questions as best as I can,
but we can consider this thread closed. I will not try to put the
virtual in, but I will come back to the list soon and start another
thread.

In a nutshell, our networking is a beast, and we should try to simplify
it some how imo. I'll write out my thoughts about that when I start the
other thread.


On Sat, Dec 14, 2013 at 11:24:10AM -0600, mingdao wrote:
> (1) What is "the new network stack" provided by the newnet USE flag?

That consists of the network and staticroute scripts which are part of
OpenRC. The network script sets up interfaces and configures static
addresses only; it will allow you to run any command at any point in the
process of doing this. What some people on Gentoo do not like about it
is it is all or nothing. You can't start/stop/depend on a single
interface.

The staticroute script is used to configure multiple static routes once
the network script has set up the static addresses.
 
> (2) Why is dhcpcd referred to as a "network manager" in the same context as
> wicd, networkmanager, connman, etc? In the sense that dhcpcd is not sufficient
> for security protected wireless alone, as is, say, wicd; and is not a
> replacement for true "network manager" apps. DHCP client != network manager
> app
 
 This is a good point, so I will drop putting dhcpcd on the list.

> (3) Is udhcpc provided by busybox not sufficient in lieu of dhcpcd for stage3? 

I think udhcpc is what you get in stage 3; if dhcpcd is there, I have no
idea how it is getting there.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[mingdao]

On Sat, Dec 14, 2013 at 06:59:50PM -0600, William Hubbs wrote:
> You make some good points. I'll answer your questions as best as I can,
> but we can consider this thread closed. I will not try to put the
> virtual in, but I will come back to the list soon and start another
> thread.
> 
> In a nutshell, our networking is a beast, and we should try to simplify
> it some how imo. I'll write out my thoughts about that when I start the
> other thread.
> 
> 
> On Sat, Dec 14, 2013 at 11:24:10AM -0600, mingdao wrote:
> > (1) What is "the new network stack" provided by the newnet USE flag?
> 
> That consists of the network and staticroute scripts which are part of
> OpenRC. The network script sets up interfaces and configures static
> addresses only; it will allow you to run any command at any point in the
> process of doing this. What some people on Gentoo do not like about it
> is it is all or nothing. You can't start/stop/depend on a single
> interface.
> 
> The staticroute script is used to configure multiple static routes once
> the network script has set up the static addresses.
>  
> > (2) Why is dhcpcd referred to as a "network manager" in the same context as
> > wicd, networkmanager, connman, etc? In the sense that dhcpcd is not sufficient
> > for security protected wireless alone, as is, say, wicd; and is not a
> > replacement for true "network manager" apps. DHCP client != network manager
> > app
>  
>  This is a good point, so I will drop putting dhcpcd on the list.
> 
> > (3) Is udhcpc provided by busybox not sufficient in lieu of dhcpcd for stage3? 
> 
> I think udhcpc is what you get in stage 3; if dhcpcd is there, I have no
> idea how it is getting there.
> 
> William

Thanks for your kind reply, William. I'm a networking n00b, but felt those
questions might benefit others, also. For (3) it seemed as if some people were
saying dhcpcd is in stage 3 and they didn't want it dropped. I have a tendency
to use busybox a lot doing a Gentoo install, starting with "ln -s /bin/busybox
/bin/vi"  :D

Kindest regards,
Bruce
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

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

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/14/2013 07:59 PM, William Hubbs wrote:
> You make some good points. I'll answer your questions as best as I can,
> but we can consider this thread closed. I will not try to put the
> virtual in, but I will come back to the list soon and start another
> thread.
> 
> In a nutshell, our networking is a beast, and we should try to simplify
> it some how imo. I'll write out my thoughts about that when I start the
> other thread.
> 
> 
> On Sat, Dec 14, 2013 at 11:24:10AM -0600, mingdao wrote:
>> (1) What is "the new network stack" provided by the newnet USE flag?
> 
> That consists of the network and staticroute scripts which are part of
> OpenRC. The network script sets up interfaces and configures static
> addresses only; it will allow you to run any command at any point in the
> process of doing this. What some people on Gentoo do not like about it
> is it is all or nothing. You can't start/stop/depend on a single
> interface.
> 
> The staticroute script is used to configure multiple static routes once
> the network script has set up the static addresses.
>  
>> (2) Why is dhcpcd referred to as a "network manager" in the same context as
>> wicd, networkmanager, connman, etc? In the sense that dhcpcd is not sufficient
>> for security protected wireless alone, as is, say, wicd; and is not a
>> replacement for true "network manager" apps. DHCP client != network manager
>> app
>  
>  This is a good point, so I will drop putting dhcpcd on the list.
So wait, who makes the call now?  dhcpcd is totally a network manager
for a lot of people who don't need wifi.  It has init scripts and
everything....

- -Zero
> 
>> (3) Is udhcpc provided by busybox not sufficient in lieu of dhcpcd for stage3? 
> 
> I think udhcpc is what you get in stage 3; if dhcpcd is there, I have no
> idea how it is getting there.
> 
> William
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSr4GkAAoJEKXdFCfdEflKoacP/3SvAZCABR0uJnZtE5Om4ZLx
qnT0Tmdh9asrSQZdfLykYVms8WXkmfG7S/C2O+acWxaTSHP5oNp1KrWufketuKob
i+CS9PjnF/EsRyj1Xw/XmYUfOKzrOeob+ePS3iYIw+y8kegQp0A12O60jJhVEAtQ
0aK59HhOZtDPvdA0A2c8X3Ar1LEFy/TbuCB7wO7BhfMlNZMr86cdy2xVSGcZfAaT
ri9B0qvK22L1HckN21nPbA7e9tM5DB9nio02YuB54Yng0Z2dS4wL5pdniftrIlMd
ah3svtRozXcd3VyRJAu26ONKWzQCrUeqZN6qR/x5JSJBjElHbyN1ah0wMvhyujIV
QfTyukokIEiSJSgGw5B5IhmnwBVXNVzZHVI5J7LwGOGzR1iNM3QIwuH54Ws7PLvs
62G4m+Lybl+tqkVOv/BZ8/xY1JxHARJYFIthjlRtQQyG6/aaFIxpbGmzso65gMyK
9Q9kSj3dppG9wAzrhEfQ17qEwfqfX1JhvBrPJdJxSIfHiiVS8kDBSXT5cWmA1GWG
JVek8SBMCr92STEzfBd8vNE5UCcvrl5RO3uu1xZBIgK+gCNJEnbTKET5EHbuZrRJ
4s0JEDuXMGM82AaQC5O4DEpUH0d48O/IzmXey9UyExV3Vsu1BlIoOV7NFCfXX6Pd
k44DP5R36SmSSsY3MYI8
=hl2B
-----END PGP SIGNATURE-----

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

[Patrick Lauer]

On 12/09/2013 10:50 PM, Rick "Zero_Chaos" Farina wrote:
> On 12/08/2013 05:25 PM, William Hubbs wrote:
>> On Sat, Dec 07, 2013 at 12:52:08AM -0500, Rick "Zero_Chaos" Farina wrote:
>>> 1.) If we are going to stuff this into @system then we probably want a
>>> USE=nonet flag to allow users to not pull anything in if they really
>>> don't want it.
> 
>> We don't have to put this in @system at all. We could just have a
>> virtual/network-manager, like we have virtual/cron, virtual/logger,
>> virtual/mta, etc. None of these are installed by default; you have to
>> choose one as part of your installation process. The more I read this
>> thread, the more I agree with this approach; let the user make the
>> choice as part of the installation process.
> 
>>> Just as a side note, after reading the thread up through this point, I'm
>>> terrified of the individuals who wish to remove networking support from
>>> stage3 entirely.  If anyone wants to push that idea then that needs to
>>> be addressed by the council.  Period.  Such a major change is going to
>>> cause a holy war, and myself and others will actively revert any change
>>> which removes net from stage3 under the guise of "critical breakage"
>>> unless there is council direction that says we are no longer including
>>> net support in the stage3s.
> 
>> I am in agreement with Rich and Peter. This isn't a matter of breaking
>> the stages; it is a matter of us getting out of the way and letting the
>> users pick the network stack they want. We do this for the kernel, boot
>> loader, etc, so I don't understand why you feel we need council
>> direction to make a similar change for the network manager.
> 
> 
> I am softening a bit, but I'm really concerned that the stages all of a
> sudden not having net is going to be an issue for people.  Maybe I'm
> mistaken, but it is hard for me to imagine that moving to a stage3 with
> no net anything is an improvement.  I suppose you can't download a
> stage3 without net, so you should typically be able to just chroot in...

And again I point at the precedent of having dhcp in stage3, then
removing it and people getting quite frustrated with having no way to
enable net properly.

We had the same type of problem before, and it was fixed.

Why are we trying to break it again, just so we fix it a week later when
the complaints become loud enough?

> I can honestly say most of the time when setup my arm systems I'm
> unpacking the arm stage3 on an amd64 and then booting the arm device
> with the base stage3 and fixing things from there.  I suppose it is
> possible to use qemu to install things, as long as I don't mind
> pretending it's 1999 due to the slow emulation speeds...  Yeah, I really
> don't see an improvement here.  It works fine for "I'm an amd64 user and
> that's all I'll ever use" but when you start talking about smaller
> arches it really starts to become a hassle imho.
> 
> -Zero
>