[maemo-developers] Busybox version

[From: Marius Vollmer]

Hi!

I didn't really try to understand how you would be setting up the
various packges exactly, so I will only try to clarify the lock-down
mechanism a bit and ways to get around them.

(As to busybox itself, my gut tells me to just use coreutils etc in ITOS
and eat the resource increase that this causes.  If we get performance
problems with shell scripts (because the coreutils are slower than
busybox), we should consider rewriting them in Perl
or C, together with Debian if we share them.)

"ext Graham Cobb" <g+770 at cobb.uk.net> writes:

> That is the killer.  The whole point of this mechanism has to be that
> it works WITHOUT removing the lock!

What you refer to as "The Lock" is the osso-software-version-rx34 or
osso-software-verision-rx44 package which 'locks down' the set of
installed packages.  It does this by depending on all individual
packages (with exact versions) that Nokia thinks that users should have
installed.

The only point of doing this is to protect users from accidents.  We
don't try to satisfy any misguided security or legal requirements with
this.  So as long as we find an arrangement that keeps the risk of
accidents low, anything goes.

You seem to be asking for changes to the osso-software-version-foo meta
packages so that they would allow some latitude for that installed
packages.  I don't think we should do that.  Instead, we should provide
additional, alternative meta packages that represent different
configurations, and we should also improve our packages so that apt-get
dist-upgrade actually works and to improve the Application manager so
that it can do a dist-upgrade in the UI.

We could provide a maemo-software-version-rx34, say, that is mostly
identical with osso-software-version-rx34 except that it uses a
different kernel, different busybox, coreutils, etc.

We should also give people the chance to to live completely freely,
without any meta packages that try to control their configuration,
Debian style.  Right now, I think this has a significant risk of killing
your OS installation, unfortunately.

> 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.

This would be specific to busybox and would need cooperation from
Nokia.  I think it would be better to find an arrangement that works in
general and that doesn't require waiting for Nokia to do something.

> 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.

What about dpkg-divert, or just using Replace (without Conflict) to
overwrite the busybox symlinks from your package.