[maemo-developers] Busybox version

[From: Eero Tamminen]

Hi,

ext Eero Tamminen wrote:
> ext Marius Vollmer wrote:
>>> 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. 
> 
> dpkg-divert requires modifying each package replacing anything from
> Busybox, updates-alternatives requires modifying both busybox and
> each package replacing anything from Busybox.  The symbol links
> proposal requires changing just busybox package but doesn't work
> as well for OS upgrades.

I've finally had time to finish/try first proto of this splitup thing.
However, the OS/Busybox upgrade may be a bit more complicated than
I though.

The problem is that because Busybox package won't anymore provide
any symlinks by itself, and all symlink packages depend from exact
Busybox version[1], all the symlinks disappear when a new version of
the busybox package is installed.  However, "rm" and "tar" are needed
to be able to continue installing the updated symlink packages.

[1] To make sure that Busybox really includes all tools which are
     symlinked to it.


There are couple of solutions for this:

1) OS upgrade adds temporary "rm" & "tar" symlinks to Busybox until
    busybox & symlinks packages are updated.  Downside is that then
    upgrading just Busybox wouldn't work unless one creates these
    symlinks manually beforehand, so I don't think this is good enough.

2) The exact version dependency to busybox is removed from the symlink
    packages.  This allows keeping the old symlinks when Busybox is
    upgraded.  The downside is that then there's nothing guaranteeing
    that the Busybox configuration matches what the symlink packages
    expect.

I think 2) would be acceptable if only Busybox symlink packages marked
as essential have this generic dependency.  For those we should anyway
have much stricter control of what busybox provides for them.  Busybox
source package modified to support the symlink packages could e.g.
reject configurations that don't include certain required binaries.


(If somebody would want to upgrade Diablo Busybox to this kind of new
version of Busybox package, a kludge like 1) would still be needed and
new Busybox would need to be installed before the symlinks packages.)


Comments?


> However, I don't think that is a problem because busybox symlink
> packages split up doesn't prevent from using dpkg-diverts in the
> replacements or putting them to /usr/local.  So, I think the split
> up is the best solution to start with.
> 
> Somebody could also add later the alternatives support to busybox in
> addition to the symlinks package split up. Though first I would like
> to see a list of which busybox utilities need this with some
> explanations why (it isn't e.g. something that should be fixed in
> Busybox itself).  Maybe there could be a wiki page listing Busybox
> shortcomings?


	- Eero