[gentoo-dev] Re: How help in arch testing work

[Duncan]

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