[maemo-developers] Busybox version

[From: Graham Cobb]

On Wednesday 20 August 2008 13:58:07 Marius Vollmer wrote:
> 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.

Thanks for the input, Marius.

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

OK.  And is this package somehow involved in the notification of system 
upgrades to users?  Does AppMgr treat it specially?  If so, what makes it 
special?

In addition, aren't there some locks around repositories that can be used to 
replace some (which?) packages?

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

Hmm.  I am not keen on that idea -- it still doesn't allow the user 
flexibility in the combination of packages.

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

I like the idea of using Replaces -- that had not occurred to me.  We leave 
the system busybox package installed and can also install other packages 
that "Replaces: busybox" and include replacements for the appropriate subset 
of busybox links.  So, for example, a gnu tar package could Replaces: busybox 
and install /bin/tar.  A procps package could do the same.

I am not certain what would happen when busybox was upgraded.  I am not quite 
sure whether dpkg will restore the links to being owned by busybox or will 
honour the replacement.  I presume it would continue to honour the 
replacement unless busybox also claimed Replaces: tar.

This feels like it might work for installing the real utilities.  For 
replacing busybox itself I am not sure it works so well -- there is a danger 
the busybox package could end up "disappeared" (see 
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces), 
which would presumably cause the lock package to be either removed or broken.  
I haven't tried this so I don't know what would actually happen.

There is also a potential problem when the replacing package is removed.  
Presumably the installed file is removed but busybox's link is not restored.

Graham