[maemo-developers] Busybox version

[From: Graham Cobb]

On Thursday 14 August 2008 17:10:50 Eero Tamminen wrote:
> So far this is mostly just an idea, if you notice any holes in it,
> please shoot...

I think it is great to discuss how we might be able to fix this issue.

> > ITOS would ship with a package called busybox-maemo which
> > installed /bin/busybox.
>
> It would be called just busybox.

OK

> Note that the main issue that I though this would fix is being able to
> install the real tools without screwing up the system.  (Personally
> I'm missing real tools from procps; proper top & ps, slabtop etc).

This affects the coreutils tools as well.  I think people are also missing 
proper ls and didn't someone on the list complain about sort -k earlier 
today?  

> > ITOS would also ship with busybox-symlinks-coreutils which depends on
> > busybox-maemo and links everything in the normal debain coreutils
> > (including pinky) to /bin/busybox.  Note that at this point ls would work
> > and pinky would appear to exist but would not actually work.
>
> How I thought this would work is that:
> - the symlinks package would contain symlinks *only* to utilities
>    included into the busybox binary[1]
> - the dependency from symlinks package to busybox would be versioned
>    (exact version to guarantee that the list of included tools and their
>    symlinks would match)

So, you are saying that if someone wants the full ls (for example) they will 
install the real coreutils package (replacing busybox-symlinks-coreutils) and 
busybox will no longer be used for any of the coreutils commands (but could 
continue to be used for procps commands, for example).

That would work.

> > ITOS also ships with busybox-symlinks-tar which links tar to
> > /bin/busybox.
>
> And Provides/Replaces/Conflicts with tar package.

OK.

> Maemo busybox replacement case isn't improved with this proposal,
> but I don't think this is really an issue that would need solving.

All right.  I had thought this would be useful (partly because it is an easy 
way to get more options for some of these commands without porting the whole 
of coreutils, procps, etc.).  But I agree it isn't absolutely necessary.

> So, the rare exceptions needing real GNU tar would depend on tar and
> conflict with busybox-symlinks-tar (if it's know that the problem
> is fixed in a newer busybox version, it could conflict with version
> smaller than the fixed upstream busybox version).
>
> All other packages needing just some tar, depend just on tar.

OK

> > That could work but ONLY if Nokia allow busybox-maemo and
> > busybox-symlinks-tar to be replaced (and this works even through OS
> > upgrades).  That seems unlikely to me.
>
> That would be a configuration that Nokia hasn't tested, so I don't see
> how we could support it in the consumer sense.  As to "allowing" the
> replacement AFAIK only thing needed before replacing any of the
> pre-installed packages is that you remove the "lock" meta-package?

That is the killer.  The whole point of this mechanism has to be that it works 
WITHOUT removing the lock!  If you are going to remove the lock you can do 
anything you want anyway.  And, as I understand it, if you remove the lock 
you never get any OS updates again.

The whole point of my "alternatives" proposal is that it doesn't need to 
remove the lock.  No Nokia components are ever removed, and Nokia OS upgrades 
continue to upgrade the Nokia-provided alternatives as usual, but the user 
can choose (through the alternatives mechanism) to not use those but to use 
others instead.

The aim is to have a process which allows users to replace busybox utilities 
with full-functioning ones with the same level of "unsupport" that anyone who 
installs any non-Nokia software sees.  There should be no need for them to 
be "more unsupported" just because they need the complete sort options 
available.

If my alternatives proposal is too complex, I do have another option: the 
ported packages are changed to install the utilities into /usr/local/ and 
users (or packages) which want to use them learn to put /usr/local/bin in 
their path before the standard locations.  Again, it requires changes to all 
the 90 packages but it can be done with no co-operation from Nokia and 
without giving up support. Personally I prefer the alternatives mechanism -- 
you can easily control and check what is happening on a per-command basis -- 
but the PATH mechanism would also work.

> I'm not really familiar with how the OS upgrades work though, so
> please correct me if I'm wrong and somebody else needs to answer
> (or test :-)) what happens when trying to OS upgrade a system that
> has been unlocked and where some of the system packages have been
> replaced.

Yes, we need someone who understands the lock and upgrade mechanisms to jump 
in!

Graham