[maemo-developers] busybox applet selection (again)

[From: Eero Tamminen]

Hi,

ext Damien Moore wrote:
> On 1/2/08, Eero Tamminen <eero.tamminen at nokia.com> wrote:
>> 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.
> 
> Shouldn't need to remove any device software if REPLACES is used and if any
> dependencies in the system respect treat the replacement as equivalent to
> the original. The only dangerous thing is that dpkg scripts presumably rely
> on busybox being there: at some point during install the old busybox is
> replaced by the new one, old symlinks are replaced by new and we have make
> sure that this won't create problems.

The problematic use-case would be trying to install a new package that
works with the default busybox but depends/requires something that is in
a Debian package from which only some binaries were included into
busybox-max, but not that required one.

With default Busybox the co. package would be automatically installed
(as its contents don't conflict with busybox) and everything is fine.
With busybox-max developer would need to replace busybox-max with the
default busybox to be able to install the new package and its deps.

This is fairly unlikely case, but IMHO reason enough not to have two
busybox versions with different set of tools.  Main thing is that the
developer can get the required tool, not whether it's in Busybox
I think.


>> 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).
> 
> good to know. although sometimes I find the absence of docs an obstacle
> (would be nice if they could be saved to one of the mmcs)

I think you can just do "apt-get remove docpurge" if you don't like
this. Unfortunately it doesn't restore the docs that were removed
before this. :-)


>> 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.
>> 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.
> 
> I'll think about this. If it is really true that binary size doesn't matter,

It matters, but less.  And it depends on whether that functionality
needs to be pre-installed.  If it doesn't need to be pre-installed
size is not really a concern with most packages.  Developers can
install only the tools they care about and e.g. keep rest on an
MMC card.


 > then that's a strong case for not using busybox at all
 > (or at least offering a full versioned drop in toolset replacement
 > for busybox)

Busybox is pre-installed.


>> 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.
> 
> that's why I advocated making it optional. to resolve the conflict,
> reinstall the slimmed down one.
> Can busybox be configured to use shared libraries for classes of toolsets?
> that way, optional packages could be provide distinct functionality in a
> shared object with accompanying symlinks without the need to overwrite the
> busybox binary.

They would be pretty small libraries and not shared by any other
binaries.  Shared libraries include both startup (symbol resolving),
and RAM cost (please read Depper's dsohowto), and don't really solve
the problem of different busybox versions having different conflicts.

Do all Busybox target platforms even support shared libraries (I doubt
the chances of this patch getting to upstream Busybox)?


>> 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
> ....
>> 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?
> 
> ok, at the very least I think all of the coreutils should be available with
> more options switched on (personal favorites: diff, patch, color coded ls
> etc).

Diff is both a Debian essential and in POSIX standard so I guess it's 
addition could be considered for maemo base system.  If(?) Busybox diff
is good enough for dpkg (for showing config file diffs on upgrade),
it could be provided by Bysybox.

Other similar binaries would be clear, logname, nice, nohup, od,
split and sum. Except for the first one, in Debian they are all
in coreutils package.  Maybe you could make a bug about these with
me on CC, I can then add it to our internal system (they are "API"
changes so they need to go through certain review process).


Patch is neither a Debian essential nor needs to be pre-installed
(when size matters more), so it should be a separate package.


> I'd also like to have all of the archive tools available but maybe I'm
> in the minority. Even a busybox with virtually everything switched on is
> only 740kb binary. I can't imagine RAM usage would be an issue. I'll add
> more later, when I file the bug

Could you list all the options you're interested about which don't
add new tools, but enhance the existing ones?


>> 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)?
> 
> the problem isn't a specific one, it's a general one. 1. it requires a
> package hunt to create a working system (perhaps this is resolved by the
> creation of a super package that installs all of the others).

Useful extra tools could get supported/documented by maemo SDK:
	http://maemo.org/development/tools/


> 2. I can't
> help but think there will inevitably be small patches to the debian packages
> that makes maintenance of many sets of packages a nightmare. Maybe I'm wrong
> about that.

The more Debian compatible maemo is, the less changes are needed for
packages.  If changes are needed because the tool doesn't work properly
on ARM, those changes should be propagated back to upstream.

Things like docpurge and localepurge could be used to handle removal
of unnecessary files (the downloaded packages are a bit larger because
they would still be in the package, but at least developer could then
control himself whether to have them stripped).

Removing other extra stuff from packages is also bad because that makes
the package less compatible with upstream.  It's better to discuss with
upstream distro (Debian) about splitting the binary packages further.


	- Eero