2010/9/19 Graham Cobb <[email protected]>: > On Saturday 18 September 2010 20:58:23 Carsten Munk wrote: >> If you have an API you'd like to share with the world, put it in >> Staging and take responsibility for it. > > But not all the packages that form part of an Application will be built from > the same source package or be suitable for general use by the world. > Consider any "suite" of related applications (e.g. an office suite or a set > of games using a common engine or the GPE suite). These will generally > consist of several apps (of which the user may install one or more) and > several libraries which support those apps but which are "internal" to the > suite.
For good measure, I don't claim that we can make everyone happy. My approach is from the simple fact we need to be able to test these things in advance. Each compliance rule must be automatically testable by a machine, IMHO. We can possibly, in the long run, make everyone happy but we need to have things like Staging, proper procedure and automatic tests to make things work. > >> * Remove all dependencies which originate from the installation source >> and is produced by the same source package as application > > A workable condition might be to say "maintained by the same maintainer" > (instead of "produced by the same source package"). In that case, we would > still be able to avoid the problem of someone else making incompatible > changes to the library (because it is owned by the same person who owns the > app). The only thing I can see as working is if we mandate seperation into individual /opt/com.whatever/libSDL/ and so on. And only Staging libs may install into /usr/lib .. The key is: Compliant packages should -never- conflict and we need to make rules that mandate this and test cases to validate this. > Personally I don't think Staging is needed as part of the Compliance > definition (it might be needed for other reasons). The rule should be: an > app can depend on any other package which is maintained by the same entity > (person/company/project team/whatever) and which is available from the same > repository. Can we test this rule properly? Staging would have to be part of compliance for the reason that we can't assume a MeeGo compliant app would install otherwise. > > If an app store doesn't make packages available as a repository (for example > it sends an RPM to the device) then the app-store app on the device would > have to be extended very slightly to be able to receive multiple rpms (for > example as a zipfile or tar file), split them out and install all of them. > This is not a heavyweight requirement for any device vendor (MeeGo could even > provide example code). I have a rubber-paragraph with the definition of 'repository' for cases like this. Best regards, Carsten Munk _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
