[BusyBox] Division of work.

[Glenn McGrath]

"Vladimir N. Oleynik" wrote:
> 
> Glenn McGrath wrote:
> 
> > Im wondering what the best aproach is to handle debian/debian-installer
> > specific applets.
> >
> > Applets in this catagory could be
> > ar,     (probably fileutils, but probably mostly used for debian)
> > dpkg,
> > dpkg-deb,
> > dpkg-scanpackages, (i intend to write it)
> > others, the bb style of code reuse could make it really good
> > (easy/efficient) for implementing numerous other dpkg- tools
> >
> > It may be tidier if they had their own group as it caters for a specific
> > group of people.
> 
> Hmm, debian is sponsor? ;))
> 
Well, busybox started out as an internal debian project for the
installer.
My primary reason for working on busybox is to develop ways for using it
in the new installer that is being developed. I hape to have a small
static busybox initrd that can unpack .deb packages to create the root
filesystem on a virtual memmory fs (shmfs/tmpfs) 

> For Slackware requires:
> 1) dialog. But this require good libncurses. Uclibc not have this.
> 2) Good shell. Busybox politic with this very strange. :(
> 3) Very strong testing all apllets and correct instalation scripts for
> remove trivialisation effects in busybox applets.
> 
> For RedHat? RPM? Ohhh... ;)
> 
If more distributions use busybox then that will be good for busybox.
Im not really familiar with slackware, havent installer it for years, im
not familiar with the development proccess for slackware either, is it
open ?

Redhat uses a python based installer, they dont provide a rescue shell
or anything, they would have to change their installer design before
busybox would be usefull to them, i think.
To be able to better handle RPM's busybox would need the CPIO applet,
which i have thought about, but havent gotten arround to, its a fair way
down on my priority list.

> > >  - Turn utility.c into libbusybox.
> > >
> >
> > It will be interesting what policy is implemented in deciding what
> > does/doesnt belong in libbusybox.
> 
> And put this ideas to ALL GNU authors! :)))
> 
> Not humor:
> Xerror_msg* ALREADY in glibc. This code in busybox is out-date specific.
> update.c can rewrite with daemon() function also already in glibc.
> 
> I think, progress in busybox brake from uclibc and libc5-compatibile.
> (Exuse me, Manuel ;) )
> 

uClibc is a real space saver for me, i love it.

Im sure you like saving space as well, so i assume you dislike it mostly
for technical reasons, i dont care so much about this, i just care that
it works. 


Glenn