[maemo-developers] [maemo-developers] Re: [maemo-users] 'Locking down' software installation

[From: Naba Kumar]

Marius Vollmer wrote:
> 
> The goal is to provide system software updates to the user with the
> property that when the user installs them, we can be reasonably sure
> that he has the packages on the device that we want him to have, and
> that he doesn't drift out of this supported configuration by accident.
> 
First of all, I think I need a well understanding of when a device is
no longer in 'supported configuration'. You said the meta-package is
meant to draw that line.

However, so far my understanding is that blue-pill and the associated
warning dialogs draw the line. I can not install/updgrade any of the
system package in blue pill mode because Application Manager does not
allow it with non Nokia-signed packages. That already effectively locks
the device in 'supported mode', IMHO.

When one enters red-pill mode and update a system package AM, shows a
warning message the package is not from nokia and therefore is not
supported. Presumably, the whole device also exits warranty/support
system at that point. Please correct me if I am wrong (not so much of a
legal expert here).

> In other words, when we announce a system update with the words
> "OS2008 release 2.1 is available.  It upgrades Flash support to Flash
> 10." we have to be sure that Flash 10 is actually working after the
> user has installed that update.  Also, the availability of that update
> must not put those users in danger that decide not to install it.
> 
I understand that applies only in 'supported mode'? Once the user is in
the wild (either by uninstalling the lock-down meta package, forcing
upgrades in red-pill mode, or both) Nokia does not care anymore about
his support. Right? He took the risk of updating the system pacakges, he
then takes the risk of making sure it works with available OS2008 update
also.

I hope you see the problem with current lock-down. The red-pill mode is
no longer about opening the 'can' as it used to be (removing the
meta-package doesn't count because it removes a huge feature from the
device, i.e. future updatibility).

And it's not just nokia-beta related. Any 3 party can come across this
issue. We are the first one to encounter it, but it is very easy to get
in the way. Community impression won't be nice too.

> Now, if a system update is available, it might be that applications
> start depending on versions of packages that are in this update.  If a
> user installs such an application without installing the system update
> first, this might pull in a part of the system update.
> 
Now, I see that this can happen in supported-mode too because the
partial update involves nokia-signed packages. However, locking
meta-package sounds artificial to solve this. Perhaps, there is a better
approach to avoid this?

> We want to avoid this situation since we only want to support
> complete, 'official' configurations.  This is because we have only
> tested these configurations, and we very likely only have
> certifications (such as "Supports Flash 9") for these configurations.
> 
> Thus, instead of silently installing a partial system update when
> installing an application that depends on some of its packages, we
> want to make it so that the user is given the clear indication that
> s/he needs to install the system update first.
> 
I fully agree with you. That's why I suggested to explore alternative to
this. As I see the goal is to:

1) In blue pill mode, we don't allow any non-nokia signed packages to
upgrade system components (already the case now).

2) In blue pill mode, we don't allow any (even nokia signed packages) to
upgrade system components *if* it doesn't come with meta-package upgrade
(i.e. complete system upgrade). This is what the lock-down meta-package
is supposed to fix.

3) In red pill mode, we allow upgrading of any package - nokia signed or
not. With appropriate warnings, of course. This is not the case now
because of the lock-down. This is the part which needs fixing.

I have couple of random suggestions, but AM experts will have to explore
more.

A) Leave meta-package with '>=' deps. But in blue pill mode, let AM
prevent any update of system package (I believe they are identified by
some package tag) *if* the composite update does not contain
meta-package also. It might require hard-coding the meta-package name in
AM. In red pill mode, AM can proceed with a warning.

B) Have there two meta-packages; one with '=' deps and other with '>='
deps. In default blue-pill mode, meta-package with '=' deps can be
pre-installed. When AM switches to red-pill mode, uninstall '=' version
and install '>=' version. When AM leaves red-pill mode, uninstall '>='
version and install '=' version. The last step will fail if system
package update happened during the red-pill mode period, then just show
the message 'Your installation in red pill mode updated system packages,
so your device stays in red pill mode'.

> 
> The complication is that installing the rtcomm beta will have to make
> sure that the version lock-down package is removed, effectively
> 'unlocking' the system.

Realizing that meta-package is supposed to be there for future system
updates (notified in AM and conveniently installed), we instead install
'custom version' of osso-software-version that removes the lock on our
packages. There will be horde of conflicts if everyone tries to do that.
The point was not to rip-off the user from a nice feature.

> Removing the version lock-down package is the
> Right Thing for betas that target Chinook, I would say.
> 
It's not the right thing because it unfairly (and unnecessarily)
excludes the red pill mode users from a fundamental update cycle.

>> If the purpose of the package is *also* to prevent the user from
>> screwing his device by installing some 3rd party updates, isn't that
>> already taken care by red/blue pill modes?
> 
> No, why do you think that?
> 
What is red/blue pill modes for other then protecting the device from 
system packages update?

> The idea isn't that you just go to red-pill mode and all the
> lock-down has disappeared.  The idea is that you can hack your way out
> of the lock-down in red-pill mode, for example by removing
> osso-software-version or by updating it from a source that has not
> been signed by the Nokia System Update key.
> 
That idea is not good because I understand that package is used for 
meta-update of the system later. Perhaps, as a (C) alternative, you put 
this meta package with '=' deps  in maemo repo. Any update, including 
nokia betas, expecting system  package update can then just set a 
dependency on it. That way there won't be any conflict from multiple 
vendors and all works fine in red pill mode.

But then if all 3rd party packages depend on this 'unlocked' 
meta-package, what would be the point of the 'lock-down' meta package in 
the first place anyway. Seeing the version change in 'About' dialog is 
certainly not the only point of locking - unlocking. Is it?

Thanks.

Regards,
-Naba