Em Quarta-feira 08 Setembro 2010, às 08:55:54, Marius Vollmer escreveu: > 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).
You're describing here a Store that doesn't push individual packages (.rpm)
files, but instead an installation instruction that includes adding a
repository if necessary.
I like that.
> > 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.
The problem here is that we're trying to define what a MeeGo-compliant package
is. See below.
> > 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"?)
Well, the only repository that you can count on being available on *all*
devices is the Core repository.
If you restrict your app to a particular vendor or profile, you can probably
get away with their specific repositories too. For example, a Handset-specific
application could depend on something that is on the Handset profile, but not
the Netbook one.
I would personally like to see the Community repository (e.g. Maemo Extras)
also as dependable. This would require that it comes pre-configured and enabled
on all MeeGo devices. However, I don't know if this will fly with all ODMs --
quality & certification issues.
> 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.
Yes. Note that here you haven't specified where the dependencies must be.
> 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.)
My recommendation and conclusion is then the following:
1) packages are allowed to have dependencies that are not pre-installed on the
device. This means the installation mechanism must have dependency resolution
enabled. (in other words, it should go through yum/zypper, not straight to
rpm)
2) the only repository guaranteed to be always enabled in all MeeGo devices is
the Core profile repository
3) [wish] the Open Source, community repository should also be enabled on all
devices so it's an allowed source of packages too, even if it triggers a
warning that the packages there are not QA'ed
4) profile-specific repositories (handset, netbook, tablet, ivi, stb, etc.) are
allowed if the vendor is aware that the package will not install on all
devices. The spec should say that this is not recommended.
5) use of other repositories makes it not MeeGo compliant, but is tolerated by
use of stores. These are governed by the rules of the specific store the
application is being submitted to.
Any third-party repository falls under rule #5, which may include someone's
personal repository, something like Extras-Testing and Extras-Devel, vendor-
specific repositories (containing overlays for things like GL drivers), etc.
--
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
