"ext Levi Bard" <taktaktaktaktaktaktaktaktaktak at gmail.com> writes: > Say you've just released an OS metapackage, maemo 3.1 sturgeon, and > then one the guys working on cairo makes a huge breakthrough in > speed and stability. You want users to be able to upgrade, but now > you have to release a new OS metapackage to do so, [...] Yes, and I actually see this as a feature, since there is no "apt-get upgrade" functionality in the Application Manager. Users would get the newer vesion of cairo by accident, when they install or upgrade a non-hidden package that depends on cairo. Another example are security fixes: they too will require a meta package. I think the additional burdon to maintain this meta package is not too high. >> The meta package could depend on 'this version or later' [...] > > I am wholly in favor of this, as may be gathered from my previous > paragraph. And the "trusted repository" scheme means that the device > is just as locked down for support purposes. Not exactly: we do not only want to control which individual packages you can install, but also which combinations. Say there is a new version of cairo, but we figure out that we also need to upgrade the internet radio applet since it had a bug that--by chance--wasn't triggered by the old version of cairo. So we want to only support the new cairo together with the new radio applet. With a version locked meta package, we can make sure that the user gets the right combinations of packages. If you want to try out the new cairo anyway before Nokia releases the official meta package that pulls it in, you can do that of course by using apt-get or the red-pill mode.
