[maemo-developers] Busybox version and OS upgrades

[From: Eero Tamminen]

Hi,

ext Graham Cobb wrote:
> On Friday 15 August 2008 15:38:53 Eero Tamminen wrote:
>> As this isn't anymore about Busybox, but the OS upgrades,
>> I updated the subject.
> 
> I disagree, I am not interested in discussing OS upgrades.  I am interested in 
> discussing the best way for Nokia and the community to work together so that 
> the community can provide upgraded versions of the busybox applications, 
> including how they can be installed and what may be the impact on the 
> usability of the system.  While the original subject may not be ideal it is 
> good enough.  

I added the OS upgrades to the subject so that Marius notices this.
(He might not be interested (read mails) about Busybox version. :-))


>> In both cases either the binaries are locked, or Nokia trusts the
>> replacements user installs to work well enough for the OS upgrade (whether
>> they're implemented in Busybox case as symlink replacements or using
>> Debian alternatives is irrelevant).
> 
> Yes, I would expect Nokia to trust community produced replacements for 
> standard Unix utilities (the sort of thing included in busybox).  That 
> constitutes a very small risk -- much less than the risk from allowing 
> community packages to install files into /etc/rc*.  I would expect that any 
> community replacement for a busybox application which did not work well would 
> be very quickly spotted.

This would require that the replacements are checked to:
- Implement the same API (command line options) as the replaced
   parts of Busybox functionality[1]
- Those options have the same semantics, or if they don't, it's
   checked that nothing in the device relies on the options with
   different semantics[2] (/etc/-dir scripts, package pre- and
   post-install scripts etc)

If this kind of checking isn't done, the incompatibilities can cause
subtle problems that aren't directly visible, they could happen just
in some specific, rare use-case.

It would be really great if the Busybox and GNU tools option
differences would be documented properly...  (for example find is
lacking a lot of options, but I think later Busybox versions are
quite a bit better in this respect.)

If the replacement commands have additional options, that's less of
an issue unless 3rd party packages start relying on them without
declaring the proper dependency to the replacement packages.

[1] http://busybox.net/downloads/BusyBox.html
[2] E.g. Busybox "ps" ignores all options given to it.  I've checked all
the scripts in the device for its use a while ago and in Diablo there
"shouldn't" be an issue for that particular command, but there might
be other similar cases.


>> To me it seems that basically you're saying that you want the upgrades
>> regardless of how the system has been modified (preferably without
>> losing your updates :-)), i.e. you don't want an OS upgrade, but
>> something more similar to the regular Debian (security etc) updates
>> you get with "apt-get update".
> 
> No, that is not what I am trying to achieve at all.  I am trying to come up 
> with a mechanism which allows people to replace busybox applets with more 
> powerful versions without disabling any system functions, including the 
> normal upgrade route.  I am taking as my working assumption that that is a 
> goal that Nokia also sees as reasonable and wants to co-operate with, not 
> prevent.
 >
> I am not too bothered if the upgrade de-installs the upgraded programs and 
> they have to be re-installed afterwards, if that is the way to get a workable 
> solution.

So the requirement is that the original lock and (at least most) other
system packages should be available from device repositories so that
user can easily re-install them before doing the lock-step OS upgrade?

Or did you mean that the application installer should do that
automatically?


> I am, however, bothered if the installation of the full tar or ls 
> results in a system which is less "supported" than the installation of any 
> other community package.
> 
>> Marius is currently on vacation.  I guess he answers once he gets back.
> 
> I look forward to hearing his insight as to how the busybox replacement ideas 
> interact with installation and upgrades.


	- Eero