After some discussions on IRC I brewed a bit on the issue and came up with the following proposal for app compliance. It's not going to make everyone happy, but I think it should be fairly technically sound..
First off, some definitions so we're all on the same page: ================================================= "Package" - RPM package "Repository" - basically meant as a typical RPM repository style repository, but provided it provides similar functionality (check for updates and retrieve updated package versions) other types are possible. "Installation source" * An URL that contains a RPM package * A online RPM repository which contains one or more RPM packages, one of which is the Application. "Application" - a RPM package which is the central component which a user interacts with. This package can depends on other components. When an application is removed, the depended-upon components which are not part of the device OS and not in otherwise use, would be removed. "Application compliance" [feel free to correct this term] Application compliance is a certificate that states that provided the following conditions are met: * The target, a MeeGo-compliant device allows installation from the installation source [reasoning for this is that there will be vendors that lock down ability to install from alternate installation sources. Chances are they will limit 'install-from-web' too then.] * The rules for application compliance are met (to be specified further down) * The rules for application compliance regarding the target's device profile is met (to be specified further down) Then: * The application will install and work on the target. __Application compliance must be automatically testable by a machine and ahead of any user installation.__ Rules for application compliance (high level) ======================================== #1 A MeeGo application is not compliant if it is downloaded from a standalone, non-repository source. The reasoning for this is that non-repository sources makes fetching updates difficult and most importantly security fixes and this poses a security risk for a user. #2 A MeeGo application may only depend on packages within: MeeGo Core repository (for the particular version of compliance it is targetted on) [this doesn't have to be repo.meego.com, can be a vendor mirror] and the MeeGo Profile repository it may be built for (or the particular version of compliance it is targetted on). Profile means Handset, Netbook, Tablet, etc. [same as above] And it's installation source. #3 With dependencies that originate within the installation source, these packages may only be packages that originate from the application's own source package. Reasoning: We should encourage same packaging practices as we have in MeeGo. This means packagename-devel, packagename-doc, etc. (bad examples for a package depending on other parts of itself) Challenges ================= Fact is that code reuse is common in both commercial and open source software. In addition to that, innovation moves faster than MeeGo release cycles. I would propose that we allow one more source of dependencies, MeeGo Staging. For what it matters, this can be added in compliance for 1.2 officially and experimented with, for 1.1. 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. Any API that exists in MeeGo staging could potentially be part of MeeGo platform or have been. It could be a reasonable testing ground for new technologies for MeeGo platform or a place to put APIs no longer part of MeeGo platform. 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. Counter-arguments such as that we can't scale bandwidth/handle this: If seen as a valuable addition by vendors these will sponsor bandwidth/akamai/etc through Linux Foundation. Examples of APIs that could go into MeeGo staging - for example Nokia Instant Community (an API for easy mesh networking and communication using it), new Qt technologies (think QML and other shared libraries). We do -not- want an explosion of repositories with conflicting packages and compliance is a way to make people contribute to adding to the MeeGo platform API through Staging instead of fragmenting. So, how does this sound? Best regards, Carsten Munk _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
