thoughts on reorganizing BB menuconfig structure?

Rob Landley rob at landley.net
Thu Mar 23 16:53:52 PST 2006


On Thursday 23 March 2006 3:41 pm, Rich Felker wrote:
> On Thu, Mar 23, 2006 at 02:39:21PM -0500, Robert P. J. Day wrote:
> > * drop "Debian Utilities" entirely and spread those entries elsewhere
>
> IMO it's informative to have these listed under Debian utilities. In
> case the user is not familiar with basic unix tools and which ones are
> essential for a normal system, putting these under Debian makes it
> clear that they're nonstandard extensions and only needed for use with
> Debian scripts or the like.

I dunno, things like "which" are of general utility.

Erik's a longstanding Debian developer, but to me debian isn't special.  (I 
use Ubuntu these days, before that Red Hat.)

Perhaps we need a miscelaneous directory, with a note in the help that this is 
mostly used by the debian installer or some such... :)

> > * move "dmesg" to "Logging Utilities"?
>
> I think it's a "Linux System Utility" because it's Linux-specific,
> unlike other tools which could work with different operating systems
> just as well.

A) Which other operating systems?

B) find . -name "*.c" | xargs grep "/proc" | sed 's/:.*//' | sort -u | wc

That finds 33 files that use /proc, which isn't portable.  And hdparm is at 
least as system-specific.

Portability cleanup work is a nice direction, and we need to start this in 
1.1.2.  (That delias guy's working on MacOS X, and Shaun Jackman's working on 
newlib.)  But I'm more in favor of tagging individual apps with dependency 
config symbols than trying to isolate them into their own menus.

> > * i don't consider "ar" to be an "Archival Utility".  i see it more as
> > a Development utility.  how many people are actually using "ar" for
> > archiving?
>
> It's not very useful as a development tool without alsohaving ranlib,
> since it can't generate the index for the contained .o files. IIRC
> either RPM or dpkg uses ar files as archives.

It has no write support at all right now.  I forget what needed it that caused 
it to be written in the first place...  According to svn 594, Glenn wrote it.

What tools does tcc (Fabrice Bellard's Tiny C Compiler) need, by the way?  I 
know it doesn't have the artificial "ld is in a separate package" strangeness 
of gcc, but it doesn't have a "make", for example...

> > * how about an entire section devoted to "Shell Applets"?  by that,
> > i mean applets normally used, say, for shell programming:
> >
> >   true, false, echo, expr, getopt, dirname, basename, length, env,
> >   printenv, printf, and lots more.
> >
> >   that would cut down the size of "Coreutils" considerably.
>
> Probably a good idea.

Busybox replaces 19 packages according to the readme.  We might want some 
other way say "give me everything you have that replaces package X" than 
having a menu for each package.  Just a thought...

> > * how about a section on "Servers"?  right now, it would be rather
> > short (telnetd, udhcpd) but who knows what else might show up there?
>
> Might be useful in the future. Probably not needed yet but couldn't
> hurt.

httpd, telnetd, udhcpd, dnsd, the _evil_ that is devfsd...

We could certainly have a "daemons" directory...

> > * several applets should be moved to "Process Utilities", such as
> > "nice", "watch", etc.  don't those qualify as "process" utilities?
>
> I think "process utilities" is just meant to be programs that need to
> look at the list of running processes, but maybe I'm mistaken.
>
> Rich

Rob
-- 
Never bet against the cheap plastic solution.


More information about the busybox mailing list