Em Terça-feira 07 Setembro 2010, às 13:27:24, Marius Vollmer escreveu: > > True, but that's more like the Store application being told to download > > more than one package to complete the installation. It doesn't sound > > like dependency management to me from the classical approach. > > > > The classic approach to dependency management is that the client side > > figures out that it needs to download extra packages in order to satisfy > > the dependencies of what it's trying to install. The case above is > > server-side dependency management: the new package is pushed to the > > client. > > Are you saying that with server side dependency management, the game > package would not formally require the engine package, and we would rely > on the Store to do the right thing? And if someone manages to shove the > game package into the device without the engine somehow, we just let it > fail mysteriously?
No, that's not what I meant.
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.
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
them?
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. This includes web-only stores, like the Ovi Store was/is for
Maemo5.
> Thus, I'd say it doesn't matter where you do the resolution, the
> packages still need to declare their requirements in the usual way.
Yes, I agree. Otherwise the user may even remove the engine and later complain
that the game broke.
> The question here is whether or not to allow a 3rd party package to
> require another 3rd party package at all. And this is indeed mostly a
> question for the Store (and the parts of it that run on the device),
> which is probably very vendor specific.
Agreed, see above.
> Unless we make a canonical MeeGo Store, which I think we should, if only
> as a technology demonstration.
>
> >> If we also figure out how to present updates to the engine package to
> >> the user, then this should work, no?
> >
> > And that's a different issue. Some upgrades may be paid for, others free.
> > And only the Store app can do that, since it needs to log in first.
>
> 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.
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.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
