[maemo-developers] busybox applet selection (again)

[From: Eero Tamminen]

Hi,

I think it's good you raised this issue as it needs some discussion.
Busybox is a base part of maemo, but we don't yet list it as an official
SDK API although most packages need/use it when they are installed.

ext Damien Moore wrote:
> I'd like to bring up the busybox applet selection issue again. This
> was previously discussed here:
> 
> http://lists.maemo.org/pipermail//maemo-developers/2007-April/009738.html
> 
> with associated bug here:
> 
> https://bugs.maemo.org/show_bug.cgi?id=989
> 
> the bug was marked WONTFIX
> 
> Eero Tamminen's resolution was to not add any additional applets to
> BusyBox because in his opinion those needs can best be met by creating
> full versions of the tools in separate packages. I don't think this is
> a good idea because it creates a proliferation of unnecessarily
> bloated packages with the attendant problems of maintaining multiple
> packages (keeping in mind that the target hardware is a capacity
> constrained tablet).

The maintenance wouldn't be a problem.  Then those packages can come
directly from Debian.  Also, then trying to install a properly working
replacement for a buggy/incomplete Busybox functionality doesn't mean
that one would need to remove first Busybox and half the device software
depending on what else Busybox provides.

As to bloatedness, there's an apt-hook installed on the device that
removes the extra docs when a package is installed (at least man & info
pages).  Developer could also run something like Debian's localepurge.
Most of the package sizes can come from documentation and localization
(which Busybox tools are lacking), sometimes also from extra binaries.
IMHO the actual binary size is significant only in fairly rare cases.


> The benefit of busybox is that most appplets add just a few kb to
> the binary size and all of them sit inside a single binary.

If they are not on the device, but separately installable packages in
a tools repository, they take even less space on most users' devices.
:-)


N8x0 devices have more Flash available than 770, so the disk usage
isn't anymore as severe issue as it was. This differs from package to
package, so the decision about this needs to be done case by case.


> My proposal is to create an alternative "essential" busybox package
> that optionally replaces the default busybox, say "busybox-max".
> busybox-max would be built with many more applets (more of the archive
> tools, more shell support (e.g. longer command histories and color
> coded ls),

I think improving the already configured Busybox functionality is a good
idea.  We're providing an xterm with the device, so it makes sense to
have what's already installed as usable as possible.

It would be nice to have a bug about that with details about what
Busybox options should/could be enabled/disabled and what will be
their effect to Busybox size & RAM usage.  What are your propositions
for enhancing the currently configured Busybox tools?


> more networking tools etc. This package would not be
> installed by default, it would just be an optional package for
> developers/hackers. I don't know how well dpkg would handle the
> package replacement but it is worth exploring.

However, I don't think it's a good idea to add more tools to Busybox.
Busybox is an essential package, so having incompatible versions of it
or trying to replace some of the binaries with the real versions will
end up with packaging conflicts.

IMHO only good reasons for adding a tool to Busybox would be
compatibility to Debian (derived distributions) from which most of
the other maemo tools come from.  I.e. if Busybox claims to provide
a certain Debian package, it should try to provide as many binaries
from that package as possible.  And even this only if:
- The real package (without docs and localization) is significantly
   larger than the corresponding Busybox binaries size
- The package in question is an essential in Debian and at least some
   of its binaries are used by the preinstalled device software


What's the problem of using the real packages / functionality instead
(specific example, please)?  E.g. if you want a good interactive shell,
why not add that as a separate package (Busybox POSIX shell would
then be used only by the shell scripts)?


	- Eero