[maemo-developers] Busybox version

[From: Marius Vollmer]

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

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

Yes.  In general, the device checks every 24 hours or so whether there
is anything new to upgrade.  If there is, the icon will blink.  This
works the same for all packages that are user-visible.

The meta package is treated specially only when constructing the menu
that drops down from the blinking icon: it is listed as a OS upgrade,
obviously.

> Does AppMgr treat it specially?  If so, what makes it special?

Yes, the meta package uses certain "Maemo-Flags" to adjust the behavior
of the Application manager UI.  They are documented here, in section
"Flags":

    http://hildon-app-mgr.garage.maemo.org/packaging-stable.html

The meta package use 'system-update' and 'reboot'.  'Reboot' is
responsible for causing the device to reboot and for the big
confirmation dialog that warns you about this.  'System-update' is used
to identify the package as a OS update for the upgrade notification
menu.  It also activates a special filter in the Application manager UI:
'system-update' packages will never be offered for installation, only
for updating already installed packages.  (This way we can have many
such meta packages in one repository without causing too much
confusion.)

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

Yes, there are also the 'package domains', explained here:

    http://hildon-app-mgr.garage.maemo.org/repos-stable.html

This is used to reject/ignore updates to packages that come from
repositories that have not been signed by the right key.

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

Yes, the meta packages are not designed to be flexible.  They are
designed to emulate the traditional approach of releasing monolithic
firmware blobs.  We are really paranoid about controlling what happens
on a users device during an OS upgrade.  For example, we will 'force'
you to sequentially install updates, without skipping one in the middle.
Thus, I don't see the meta packages allowing any other flexibility than
allowing you to remove or replace them.

> [Using "Replaces"]
>
> 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 [...]

I assume the same.  Should be easy to verify.

> 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),

You could make it so that the /usr/bin/busybox binary will never get
replaced, just the symlinks.