ext Thiago Macieira <[email protected]> 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 > repositories. > > 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 download. 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 packages. > 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. Yes. > 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 > them? 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 > Maemo5. 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. Right. > 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 > Store. Still, that's what we have to do. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
