On Sat, Sep 18, 2010 at 07:35:40PM +0200, Carsten Munk wrote: > After some discussions on IRC I brewed a bit on the issue and came up > with the following proposal for app compliance.
Thank you, that makes a lot of sense. > #2 A MeeGo application may only depend on packages within: > > MeeGo Core repository [...] > and the MeeGo Profile repository it may be built for [...] > And it's installation source. This third case is already a huge improvement. > #3 With dependencies that originate within the installation source, > these packages may only be packages that originate from the > application's own source package. I get the idea and reasoning behind it, but I can see some problems with this particular wording: - Different lib/app licencing. - Verification: the source package might not be in the installation source in the first place (non-free) in which it boils down to blindly trusting the binary RPM headers. - Reuse of components which are not reused elsewhere - the usual example of a vendor publishing a few games that use the same engine and wants to maintain/package that separately (including at source level). - Ultimately this just shifts the bundling issue to the source package, ie we can still end up with 20 instances of SDL installed as long as they are included in the .srpms of the apps that use them. > MeeGo Staging would be a repository which follows same rules as MeeGo > features. As in, someone takes responsibility of QA and maintenance > before it's approved for Staging. So IIUC Staging is essentially Surrounds with additional QA/maintenance requirements? What are those exactly? This may sound as a burden at first, but I don't think it is that much. A developer that ships something via whatever means would assume responsibility for it anyway. If another developer then comes along with a different use for it and wants API changes, in most cases they should be able to work out the details between them (and that can probably be considered an upstream issue anyway). It's not guaranteed to always be frictionless of course, but if all else fails forking or bundling are always options. BTW, it's not explicit but is the intent that packages present in Staging are not allowed in any other installation source? If so we could replace rule #3 above with a requirement that non-core OSS dependencies be hosted on Staging. Rationale: if it's OSS chances are that sooner or later someone else will have a need for it, so it's best to pre-empt repository conflicts early. That still leaves a few corner cases (eg vendor X has a proprietary game engine used in their own products but also licenced to third party developers) but these can be "solved" at worst by bundling so we're no worse off than the current proposon and this might be good enough to start with. > All API in MeeGo Staging must be OSS and work on all TSG approved > platforms (ARMv7, Atom, etc). No applications may exist in MeeGo > staging, only libraries and possibly command line tools supporting the > libraries. There's a third class of packages that should be allowed there IMHO, non-core runtime environments (different language interpreters, VMs, etc). On Sat, Sep 18, 2010 at 08:20:09PM +0200, Carsten Munk wrote: > The challenge is that if we dilute this, we risk that people dump in, > let's say, SDL and it would conflict with another repository also > hosting SDL. We won't see people putting same application in multiple > places, I would hope.. Ah, but I can easily see political games that could make this desirable, eg a vendor Foo with a policy only allowing apps from FooStore on their devices (but happy to sell FooStore apps to other devices too), while device-agnostic BarStore has better terms for the user and/or developer. L. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
