Mike Frysinger posted on Thu, 19 Jan 2012 11:46:21 -0500 as excerpted: > On Wednesday 18 January 2012 21:23:47 Duncan wrote: >> If people want it, they can merge it, just like any other package. >> Really, the same applies to busybox, and arguably, even to >> module-init-tools (and the more recent replacement, kmod...), since >> that's not needed if people choose to build all their drivers into the >> kernel. > > not really. the # of people who build their kernel without module > support is such a minority that they can suck it up and accept the > additional dep, or simply use one of the many existing knobs in > /etc/portage/ to disable it.
That's why I said "arguably, even..." for the kernel modules suggestion. I wasn't seriously making that argument, only stating that it could be made. > busybox is there because we believe Gentoo should have a rescue shell > installed for when the system/user eats things and needs recovery > without resorting to a livecd. if you never make a mistake, then you're > free to ignore it like anything else. Having other recovery arrangements (like the mentioned system backup partition, reachable with a simple alternate root= on the command line) != never make a mistake! In fact, it's precisely because I'm all too aware of the possibility of my own fat-fingering (or neural short- circuiting) as well as recognition of the fact that I DO run ~arch and even masked packages (like the live-git openrc-9999) that I set it up that way, the rootbak solution being at once both FAR more resilient than a busybox after all still installed on the same working partition that we're assuming now has major faults of an unspecified type, thus triggering the emergency in the first place, AND far more flexible, since the rootbaky solution has all of the same tools in the same configuration as the user was using at the time the backup took place. So if (as happened to a famous LWN editor at one point) an in-hindsight unwise system update shortly before a conference where an important presentation was to be made breaks the working installation, simply boot to rootbak instead, and do the presentation using a snapshot of the system taken when it was known to be working say a month or two earlier. Busybox installed on a broken partition isn't going to help; neither will busybox alone allow you to do your presentation coming up in 15 minutes, if it's going to take 30 minutes of hacking to find and fix the problem. Simply rebooting to a tested working rootbak snapshot of the system made when it WAS working, using an alternate root= on the kernel command line, allows both, and a single root= change in grub is going to be far easier than working in an unfamiliar busybox environment, as well. Of course, that implies changes to the handbook, etc, to encourage users to setup their rootbak partition (partitions, if /usr and /var are on separate partitions), and to periodically update AND TEST the rootbak system snapshot(s), when the system is known to be in a reasonably stable state. But still, openssh is certainly the low hanging fruit, here, busybox less so and not at all as long as it remains the recommended and default emergency solution, and module-init-tools/kmod is only included as an example of an excludeable should we REALLY want to get strict with @system. Meanwhile, the great thing about Gentoo is that it provides mechanisms such as /etc/portage/profile/packages for users who wish to, to make such changes on their own. On that I'm quite sure pretty much everyone here can agree, or we'd not be here discussing it in the first place! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
