On Thu, Sep 9, 2010 at 09:23, Ville M. Vainio <vivai...@gmail.com> wrote: > On Thu, Sep 9, 2010 at 11:14 AM, Andrew Flegg <and...@bleb.org> wrote: > >> That's why I'm proposing that the language in the spec recognises that >> MeeGo-compliant packages can have a canonical location (e.g. >> "repository X") and can depend on anything else in that repository. > > This would not be completely accurate either. A manufacturer way want > to create a special repository for packages that apps in their app > store CAN depend on, and this is not necessarily the repository that > the sold applications are downloaded from.
Would it be solved by introducing repository dependencies? i.e. if you have repository X, you must have repository Y. Therefore a package can depend on anything else in its canonical repository, and any repository on which that repository depends. And that all dependencies for a MeeGo-compliant package must be MeeGo-compliant packages. > - There will be a bunch of "meego compliant" applications that only > depend on what is already in meego > > - There will be a bunch of noncompliant applications that will, > nevertheless, be sold in app stores. MeeGo implementation should be > compliant with meego spec even if it allows installation & sales of > apps like this. Do we know what the impact of a package *not* being MeeGo compliant is? Will there be trademark issues if people say it's MeeGo-compatible (or for MeeGo devices), for example? Will we say we don't want to discuss any package which isn't MeeGo-compatible on the mailing lists or fora? Or is it more of a notional badge *purely* to ensure compatibility across different devices? If it's that, but it doesn't cover the common case, it's efficacy will be reduced. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
