Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-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
-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 +, 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
-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 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 >> 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
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 ^^ supp...@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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, 14 Dec 2013 15:57:04 -0600 William Hubbs wrote: > On Sat, Dec 14, 2013 at 08:47:01PM +, 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 signature.asc Description: PGP signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, Dec 14, 2013 at 08:47:01PM +, 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 # 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] signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, 14 Dec 2013, William Hubbs wrote: On Sat, Dec 14, 2013 at 05:56:33AM +, 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
On Sat, Dec 14, 2013 at 05:56:33AM +, 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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
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 ^^ supp...@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
On Sat, 7 Dec 2013 07:42:48 -0500 Rich Freeman 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
On Sat, 7 Dec 2013, Rich Freeman wrote: On Sat, Dec 7, 2013 at 12:52 AM, Rick "Zero_Chaos" Farina 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. 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
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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Tue, 2013-12-10 at 06:23 -0500, Rich Freeman wrote: > On Tue, Dec 10, 2013 at 5:31 AM, Steev Klimaszewski 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 > 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.
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Tue, Dec 10, 2013 at 5:31 AM, Steev Klimaszewski 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 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
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 > 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 set password (might as well, since you're chrooted) vim inittab 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
On Mon, Dec 9, 2013 at 2:56 PM, Rick "Zero_Chaos" Farina 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
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 >
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-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 > 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
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
On Mon, Dec 9, 2013 at 9:50 AM, Rick "Zero_Chaos" Farina 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
-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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
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
On Sat, Dec 7, 2013 at 9:22 AM, 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. > 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
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
-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
On Sat, Dec 7, 2013 at 12:52 AM, Rick "Zero_Chaos" Farina wrote: > > 2.) having dhcpcd in this list will cause everything else to be cleaned > out that that is bd. 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
-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 bd. 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
On Fri, Dec 6, 2013 at 9:26 AM, Ian Stakenvicius 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
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-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 >> wrote: >>> On 12/05/2013 05:30 AM, Mike Gilbert wrote: On Wed, Dec 4, 2013 at 4:25 PM, 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? > 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
On 05/12/13 00:36, Mike Gilbert wrote: > On Wed, Dec 4, 2013 at 5:31 PM, William Hubbs 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 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
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
On Thu, Dec 5, 2013 at 2:39 AM, Alan McKinnon 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
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
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 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
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 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.mckin...@gmail.com
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Wed, Dec 04, 2013 at 07:17:45PM -0500, Mike Gilbert wrote: > On Wed, Dec 4, 2013 at 6:45 PM, Patrick Lauer wrote: > > On 12/05/2013 05:30 AM, Mike Gilbert wrote: > >> On Wed, Dec 4, 2013 at 4:25 PM, 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? > >>> > >> > >> 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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
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 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
On Wed, Dec 4, 2013 at 6:45 PM, Patrick Lauer wrote: > On 12/05/2013 05:30 AM, Mike Gilbert wrote: >> On Wed, Dec 4, 2013 at 4:25 PM, 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? >>> >> >> 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
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 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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On 12/05/2013 05:30 AM, Mike Gilbert wrote: > On Wed, Dec 4, 2013 at 4:25 PM, 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? >> > > 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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Wed, Dec 4, 2013 at 5:31 PM, William Hubbs 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 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
On Wed, Dec 04, 2013 at 04:30:30PM -0500, Mike Gilbert wrote: > On Wed, Dec 4, 2013 at 4:25 PM, 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? > > > > 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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Wed, Dec 4, 2013 at 4:25 PM, 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? > 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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
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" 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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
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 ^^ supp...@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
On 2013-12-03, at 6:00 PM, William Hubbs wrote: > On Tue, Dec 03, 2013 at 04:43:28PM -0500, Ian Stakenvicius wrote: >> On 2013-12-03, at 4: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 >> >> 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
On Tue, Dec 03, 2013 at 04:43:28PM -0500, Ian Stakenvicius wrote: > On 2013-12-03, at 4: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 > > > > 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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On 2013-12-03, at 4:11 PM, 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" 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
On Tue, Dec 03, 2013 at 09:32:10PM +0400, Alexander V Vershilov wrote: > On Dec 3, 2013 1:24 AM, "Ian Stakenvicius" 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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Dec 3, 2013 1:24 AM, "Ian Stakenvicius" 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- >
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
-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
-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
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 signature.asc Description: Digital signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
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" 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@gmail.com] > LinkedIn: http://it.linkedin.com/in/delaurenzis > >
[gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
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@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
