Comment 1 Eero Tamminen 2008-04-28 12:34:35 UTC

(In reply to comment #0)
> OS2007.50.2 on N810
> 
> Busybox should use alternatives system (handled by update-alternatives)
> instead of "Provides/Conflicts" fields in package description.
>
> Currently it is not possible to install "procps" for example without
> "--force-depends" option.

Another possibility would be to remove procps from Busybox,
then it wouldn't anymore prevent installing the real procps.
And I too would like to have full procps, the Busybox variants
really don't cut it.

I think currently only "kill" is used from the procps binaries
Busybox provides (and "ps" by some unused scripts in unmodified
upstream Debian packages on the device), if that wouldn't be anymore
needed by the pre-installed scripts, then whole procps package wouldn't
be needed on the device.  (Full procps (several hundred kB) being
pre-installed on the device is a bit too much as most of that is just
developer/power-user tools.)

Some kind of hybrid approach between these two could also be used.

This won't happen for the next release though, hopefully after that.

Please do not rename bugs when title was properly set.

update-alternatives problem with Maemo busybox is not limited to procps but to
any package which will install one of binaries already provided by busybox.

Look at OpenEmbedded generated packages to get proper solution.

Comment 3 Eero Tamminen 2008-04-28 16:28:24 UTC

(In reply to comment #2)
> Please do not rename bugs when title was properly set.

The original bug description was only about procps. Bugs in general should
be about issues instead of using specific solutions to these issues.

Why alternatives would be a better solution than e.g. divert?
In both cases both Busybox package and the co. other package need
to be modified.


> update-alternatives problem with Maemo busybox is not limited to procps but to
> any package which will install one of binaries already provided by busybox.

I don't think it makes sense to use alternatives for all of the >100 binaries
Busybox provides in maemo (because you would need to modify also all those
other packages).

If you have issues with other packages than procps, I'm afraid you need to
file separate bugs about them, they may be considered case-by-case
(unless we could replace whole Busybox with GNU tools :-)) and may be
solved in different ways (removing binaries from Busybox, using divert or
alternatives, splitting Busybox to multiple pieces or making it easier to
replace whole Busybox with corresponding GNU tools...).

At the least you would need to list them here and give some reason
why it specifically is a problem for you.


> Look at OpenEmbedded generated packages to get proper solution.

Please provide a link.

Note that our upstream is Debian and we try not to diverge too much from it
packaging wise, but in the Busybox case it's not much help:
-----------
This package installs the BusyBox binary but does not install symlinks for
any of the supported utilities. You can use /bin/busybox --install to install
BusyBox to the current directory (you do not want to do this in / on your
Debian system!).
-----------

(In reply to comment #3)
> The original bug description was only about procps.

If I understand correctly, it was just an example.

> Bugs in general should be about issues instead of using specific solutions
> to these issues.

Here, that would be many bugs. And I don't think that the discussion about the
solution (alternatives, divert, a different directory with $PATH update...)
should take place in different bugs.

> I don't think it makes sense to use alternatives for all of the >100 binaries
> Busybox provides in maemo (because you would need to modify also all those
> other packages).

Well, when a GNU version exists, users may be interested in choosing it because
GNU tools provide more features such as color support (and may be less buggy).

> At the least you would need to list them here and give some reason
> why it specifically is a problem for you.

As for me:
egrep, fgrep, grep, ls: lack of color support.
tar: currently buggy (see bug 3033).

Also, in general, GNU tools have more documentation with the --help option.
This doesn't take much space and this is very useful.

Eero: procps was just an example - it was first package on which I got hit by
that bug.

Writing that 'Maemo follows Debian' does not help here. It is not Debian - it
just looks like in some places. I can understand that Maemo core developers
have a list of things to ignore (users which install normal versions instead of
busybox applets, users which wants i18n in their languages) but I feel that
Maemo had an attempt to be distro for embedded devices (limited to Nokia
tablets of course). When new model with few gigabytes of internal storage (used
for rootfs) appear then we can ignore fact that people want to extend their
system with normal tools instead of limited busybox versions.

Adding update-alternatives support into busybox package is simple. All you need
is /etc/busybox.links which lists all installed applets) and post-install
script which use list and add u-a call for each of them. This allow users to
generate packages which replace busybox applets with normal versions in clean,
Debian way. And thats how it is done in OpenEmbedded (so also Ångström,
OpenZaurus, Familiar, Poky, SlugOS and few other embedded devices
distributions).

Please also note that busybox in Debian is not targeted to be used as standard
system shell. It is targeted at Debian installer or other space limited systems
-- it is not for each day use.

Comment 6 Eero Tamminen 2008-04-28 19:27:00 UTC

(In reply to comment #4)
> > Bugs in general should be about issues instead of using specific solutions
> > to these issues.
> 
> Here, that would be many bugs.

Summary: "Busybox prevents installing full versions of tools packages
(cleanly)"
would be a description of the generic issue, not a solution proposal.


> Also, in general, GNU tools have more documentation with the --help option.
> This doesn't take much space and this is very useful.

Busybox documentation is here:
  http://busybox.net/downloads/BusyBox.html


(In reply to comment #5)
> Adding update-alternatives support into busybox package is simple. All you
> need is /etc/busybox.links which lists all installed applets) and post-install
> script which use list and add u-a call for each of them. This allow users to
> generate packages which replace busybox applets with normal versions in clean,
> Debian way.

This sounds quite nice.  Could you add a link to an example post-install
script?


> And thats how it is done in OpenEmbedded (so also Ångström,
> OpenZaurus, Familiar, Poky, SlugOS and few other embedded devices
> distributions).

Aren't all of these somehow related to / derived from OpenEmbedded?

> Please also note that busybox in Debian is not targeted to be used as
> standard system shell. It is targeted at Debian installer or other space
> limited systems

Duly noted.

Created an attachment (id=757) [details]
post-install script

> (In reply to comment #5)
> > Adding update-alternatives support into busybox package is simple. All you
> > need is /etc/busybox.links which lists all installed applets) and post-install
> > script which use list and add u-a call for each of them. This allow users to
> > generate packages which replace busybox applets with normal versions in clean,
> > Debian way.
> 
> This sounds quite nice.  Could you add a link to an example post-install
> script?

Attached.


> > And thats how it is done in OpenEmbedded (so also Ångström,
> > OpenZaurus, Familiar, Poky, SlugOS and few other embedded devices
> > distributions).
> 
> Aren't all of these somehow related to / derived from OpenEmbedded?

Yes, all of them were built with OpenEmbedded or derived from it. And it landed
on lot of misc devices and all of them are upgradable by packages (which Maemo
is not capable even after 4 years of existance).

(In reply to comment #6)
> Summary: "Busybox prevents installing full versions of tools packages
> (cleanly)"
> would be a description of the generic issue, not a solution proposal.

Yes, this would be better.

> Busybox documentation is here:
>   http://busybox.net/downloads/BusyBox.html

But this is not the version of the one installed on the N810. So, it may be
misleading.

Comment 9 Eero Tamminen 2008-04-29 15:40:57 UTC

(In reply to comment #7)
>> This sounds quite nice.  Could you add a link to an example post-install
>> script?
>
> Attached.

Thanks.

I had hoped it could do something smarter.  Now you need to modify
*all* Busybox tools replacement packages to:
- rename the overlapping tools to some new name
- in post-install use update-alternatives
This is pretty ugly.


(Btw: on POSIX systems, something like "bn=`basename $link`" can be replaced
with "bn=${link##*/}" which doesn't require forking subshell + exec)


(In reply to comment #5)
> Please also note that busybox in Debian is not targeted to be used as standard
> system shell. It is targeted at Debian installer or other space limited systems
> -- it is not for each day use.

Has there been any effort to propagate the proposed change to Debian
and could you provide any links to discussion about that?

I think it would be better to extend Debian update-alternatives to handle
the cases where a new package tries to overwrite an already existing
alternative link.  It could automatically divert (with e.g. new --divert
option) the new binary and set it as an alternative with default priority.
If the earlier link is with lower priority, it would be replaced with
a link to the new (diverted) binary.

Guillem, any comments on this idea?

Comment 10 Eero Tamminen 2008-05-29 19:03:08 UTC

I thought of a simpler solution.  The symlinks should be in separate packages
from the Busybox binary itself and should correspond to Debian packages
(symlinks corresponding to binaries in Debian procps package should be in
busybox-procps package etc).  This should be something acceptable to
the upstream also I think.

Comment 11 Andre Klapper 2008-06-06 14:54:13 UTC

copying from the internal ticket:

"One of the goals is to minimize difference to upstream in cases where the
differences do not have good reasons behind them." - This is going to be pushed
for Fremantle.

Comment 12 Quim Gil 2008-07-21 08:10:33 UTC

It would be good to confirm whether this problem will be fixed in Fremantle.

otoh, is this really a "major" bug wit "high" priority?

(In reply to comment #12)

> otoh, is this really a "major" bug wit "high" priority?

For me (reporter) it is. This blocks me from installing packages which extends
installed versions.

Comment 14 Andre Klapper 2008-07-21 13:49:30 UTC

Internal ticket states that this will be looked at for Fremantle.
This is not high priority, no votes, "only" one reporter complaining (sorry,
but other stuff has a higher priority because much more people run into that -
limited ressources and manpower).

(In reply to comment #13)
> For me (reporter) it is. This blocks me from installing packages which extends
> installed versions. 

This is quite annoying. But I ended up installing such software on the internal
2-GB card (with an ext3 partition), with the advantage of leaving some space on
the internal memory for other packages.

Comment 16 Eero Tamminen 2008-10-27 11:55:43 UTC

*** Bug 3825 has been marked as a duplicate of this bug. ***

Comment 17 Carsten Munk 2008-10-27 17:01:47 UTC

If jffs2 did support hard links, this would be possible to avoid - I tried
under a Debian with busybox with hard links, and then install coreutils. Didn't
nuke busybox.. It probably works differently with symbolic links

Comment 18 Eero Tamminen 2008-10-28 14:50:27 UTC

(In reply to comment #17)
> If jffs2 did support hard links, this would be possible to avoid - I tried
> under a Debian with busybox with hard links, and then install coreutils.
> Didn't nuke busybox.. It probably works differently with symbolic links

Files/binaries & their symlinks that a package installs should be in the
package database and they go there automatically if they are inside the
package.  When things are done correctly, package management will then notify
user about conflicts.

Debian Busybox doesn't install any symlinks or hardlinks, so naturally you
don't there get any package conflicts when you install coreutils.  If you
install them yourself afterwards outside the packaging system, well, root has
the freedom to break his/her system.

Comment 19 Quim Gil 2008-12-29 14:04:20 UTC

Setting priority HIGH to know what is going on here. This is blocking also an
old feature request.

Comment 20 Andre Klapper 2009-04-23 17:09:18 UTC

Work in progress according to the internal ticket.

Comment 21 Andre Klapper 2009-07-28 13:46:54 UTC

The internal ticket with all its dependencies has been finally resolved (after
the release of SDK beta 2).

As the internal ticket refers to "Debian Essentials" (and I think that this
term is not clearly defined within the Nokia team) I am not totally sure though
that it will also cover all the cases mentioned in this public bug.

Hence keeping this open. Feedback after the next release (either another
Fremantle SDK or a final Fremantle, who knows) highly welcome.

Comment 22 Eero Tamminen 2009-09-15 18:35:23 UTC

(In reply to comment #21)
> I am not totally sure though that it will also cover all the cases
> mentioned in this public bug.
> 
> Hence keeping this open. Feedback after the next release (either another
> Fremantle SDK or a final Fremantle, who knows) highly welcome.

Busybox package uses now alternatives where appropriate.  Not for everything as
suggested here (as that wouldn't work), but for things where Debian uses
alternatives (vi etc). /bin/sh is handled with a divert.

Replacing e.g. "procps" mentioned in the original bug report is now possible as
Busybox symlinks corresponding to that are in a separately replacable package.

Replacing Busybox symlinks that correspond to Debian essentials (e.g. with GNU
coreutils) isn't supported (those symlinks are included to the busybox package
itself) as that was found out to be too fragile in upgrades.


The new Busybox packaging can be created semi-automatically by Python scripts
included into the the Busybox package if/when Busybox configuration is changed.
 See docs and scripts in the Busybox source package debian/scripts/ -dir:
  http://repository.maemo.org/pool/fremantle/free/b/busybox/


Setting this as fixed in Fremantle.


Note: If something that allows replacing everything in Busybox is wanted, I
would suggest creating a replacement Busybox package that uses dpkg/apt-hook
which gets run on every package install & removal and is responsible of
creating symlinks for all Busybox tools that don't have either a symlink or a
real tool.  It should be much less work to implement (and "should" work fine),
but as it works around the package management, it's not a solution we're going
to use. 

For more info this, see the last year BB packaging discussion on the
maemo-devel list.

It is still not possible to install the grep package from fremantle/sdk.  Is
this one of those that won't work with the alternatives system?

I miss "grep -R".  I compiled GNU grep from source and installed it into /usr,
leaving /bin/grep linked to busybox, but I'm not sure this is the best way of
doing it.

Comment 24 Eero Tamminen 2010-01-21 10:04:49 UTC

(In reply to comment #23)
> I miss "grep -R".

The recursive option is "-r".  Busybox grep supports it fine.

Oh, how about that.  Well, there was another problem with grep that I ran into,
some sort of incompatibility with dpkg build scripts.  I guess I'm just
expressing my frustration that busybox is standing in my way of the N900
behaving just like any linux box for me.  Lots of incompatibilities come up,
and I've replaced all kinds of stuff in /usr/bin with binaries pulled out of
coreutils from the SDK by now.  Something to consider for Harmattan perhaps.

Comment 26 Eero Tamminen 2010-01-21 10:48:08 UTC

(In reply to comment #25)
> Oh, how about that.  Well, there was another problem with grep that I ran
> into, some sort of incompatibility with dpkg build scripts.

If there are compatibility issues with Debian package install/uninstall
scripts, please report them as bugs (and put me on CC), especially if the issue
is Busybox incompatibility to to POSIX tools API.  (If the question is about
GNU tools specific options, it's a bit less clear what should be done.)


If the issues are with _building_ software with Autotools on device, that's not
supported, but I guess you could hack around that fairly easily by putting the
GNU tools & toolchain e.g. to /usr/local/bin (with /usr/local linked to some
other place than rootfs) and setting your PATH suitably before starting the
build.


> I guess I'm just
> expressing my frustration that busybox is standing in my way of the N900
> behaving just like any linux box for me.  Lots of incompatibilities come up,
> and I've replaced all kinds of stuff in /usr/bin with binaries pulled out of
> coreutils from the SDK by now.

We don't support distro essentials (in single Busybox package) being
replaceable by completely differently packaged essentials (separate GNU tools
packages) because that's not a sane target from the upgrade point of view.

I think replacing Busybox tools symlinks "manually" with real tools should work
on upgrades too though as then dpkg just replaces the old binaries.

Non-essential parts of Busybox (most things besides coreutils stuff it provies)
are replaceable, and Fremantle Busybox packaging supports alternatives for
things that use alternatives in Debian.


> Something to consider for Harmattan perhaps.

Don't hold you breath... Although the size issue[1] would be less on Harmattan,
there are still the bootup speed[1] and GPLv2 vs. GPLv3 issue.

[1] If somebody really wants Busybox to be replaced, providing numbers about
disk usage and speed performance difference when using GNU coreutils instead of
Busybox would help, if the numbers don't seem too bad and they're reproducible
by us.