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] logging in openntpd 20080406-r3+
On Thu, Dec 5, 2013 at 6:02 AM, Paul B. Henson wrote: > Bug 493358 has a patch to fix this. With the patch, openntpd will > background within approximately 15 seconds plus however long your > resolver is configured to take to timeout a dns query. > > Perhaps now we can just ditch the syslog use flag and remove the option > to run in debugging mode with stderr redirected? I don't think there was > any need for it other than to resolve the delayed startup bug, which I'm > reasonably confident this does... Awesome! Yeah, I think this should make it possible to roll back some of those other things. I'm glad I wasn't crazy, thanks for looking into this. Cheers, Dirkjan
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
