[MeeGo-dev] Meego spec - for comment
marius.vollmer at nokia.com
Tue Sep 7 23:55:54 PDT 2010
ext Thiago Macieira <thiago at kde.org> writes:
> What I meant is that, with traditional client-side package management, if you
> obtained the .deb or .rpm from the store, the manager tool (apt, yum, zypper,
> etc.) would detect the missing dependency and request it from the
> I don't see this working for commercial (paid-for) applications on any store.
> The store needs to determine whether you have the right to obtain packages,
> including that particular game engine.
Yes. You need both, I'd say: the device knows best what it has
installed and what it has available and how to resolve dependencies
based on that, and the Store knows what the device is allowed to
In order for this to be consistent, so that the device does not try to
download something that is not available to the user, the Store needs to
do some dependency handling as well: When someone buys the game, he gets
download rights to the engine as well.
If that is not something that the Store wants to do, because it is hard
to implement and slow to execute (as it may well be), then the Store
must make the policy that none of its packages can have dependencies to
other packages in it, and enforce that during upload. The device will
still have all the fancy resolution machinery, it will simple go mostly
unused (except for detecting when a OS update is needed and as a last
defence against packages whose requirements can not be fulfilled).
However, other Stores for MeeGo devices, or more generally, other
sources of packges might want to allow dependencies between their
> This would require server-side dependency management, so the store
> should push the dependencies to the client. That is, from my point of
> view, a Store's policy.
> Is that something that MeeGo should specify? I don't know. Maybe just make
> suggestions to Store implementors and let them decide what's the best for
I propose to go further and actually implement a Store ourselves on
meego.com, if only as a demo with Monopoly money, and make its code
available for others to build their real stores with.
> If you're not using a store application, but a simple .rpm on your
> website, then you cannot rely on end-users figuring out
> dependencies. You should only depend on what's available on the core
> repositories, which are always enabled in all devices.
(Is that "core" as in MeeGo Core profile? Or "core" as in "just
meego.com, not the vendor or store specific repositories"?)
> This includes web-only stores, like the Ovi Store was/is for
It's a choice of the store, I would say, and if we give them a head
start with a demo Store and don't neglect this use case in our device
software, then some might actually do it and we have advanced the state
of the art.
In any case, it is clear to me now that 3rd party packages are allowed
to have dependencies on MeeGo packages that are not already installed in
the device, and the package management is expected to download and
install them when such a 3rd party package is installed.
Thus, we don't have to put Python into every device initially, but 3rd
parties can still use it and it will be installed together with the
first Python program.
That goes a long way, and means the device is mostly ready for
intra-store dependencies; previously I thought that a 3rd party package
can only require other packages that are guaranteed to be in every
device already. (This is the state of the Ovi Store and Maemo 5, it's
not pretty, and it's my fault, and I want us to do better than that.)
>> We have the SSO component (Single-Sign-On) also in MeeGo, no? That's
>> how we let apt-get log into the Ovi Store in Harmattan.
> Well, there are two problems with that. First, AFAIK, that SSO
> component is not part of MeeGo, only of Harmattan.
> Second, it requires that the Store credentials be stored in the SSO
> domain too and yum/zypper be taught how to obtain the credential.
Yes. This should be doable. In Harmattan, we have a dedicated "Ovi
Store Adapter" for this: It essentially makes the Ovi Store look like a
small per-user repository to apt. It knows how to download files from
the Ovi Store when requested by apt, using SSO.
This setup is ready for intra-store dependencies, although the Ovi Store
itself doesn't support them (yet).
(The main reason for the adaptor is to integrate the Ovi Store deepish
into the normal device package management UI, so that updates to Ovi
Store packages can be discovered and installed like any other update and
so that you can reinstall packages from the Ovi Store after restoring a
backup, for example. Only initial discovery and the purchase happens in
a dedicated Ovi Store client.)
> It also requires that the particular Store vendor decide to use this
> mechanism. Rolling per-user repositories, indicating what's available
> for upgrade for this *particular* user, is not a trivial task. We have
> that for Qt's commercial customers, for example, and it's a slow
> system -- and that's 3 or 4 orders of magnitude smaller than the Ovi
Still, that's what we have to do.
More information about the MeeGo-dev