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 _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
