So, I have personally lost complete track of the spec thread and decided to re-read the actual spec draft, that is, http://wiki.meego.com/images/MeeGo-Compliance-Spec-1.0.80.8.pdf
After doing this, I'm wondering what exact wording in the spec we're fighting over. What I wondered after reading the thread - We have advanced package management, repositories, dependency solving, garage clients (OCS), app store like things. but the premise seemed to be: that we resort to what's essentially: "if rpm -i packagename.rpm doesn't succeed on a fresh MeeGo device, packagename.rpm is not a MeeGo compliant application" However. Did anyone -actually- read the spec? Let's start - in reverse: 227 Compliant Application Executables 228 All MeeGo compliant application executables shall be in the ELF format as described above and they shall import external interfaces from one of the following sources: 230 • shared libraries supplied as a part of the application package; 231 • shared libraries from third party packages that are MeeGo compliant itself and are 232 listed in the RPM package dependencies; 233 • MeeGo Core shared libraries if the interface is a part of the public interface of that 234 library as it is described in Appendix B. 235 If the executable is a plugin for a MeeGo system component it may import interfaces from 236 an executable of the system component and from shared libraries loading as part of that 237 executable. 238 Additionally, the executable may use public interfaces from shared libraries specific to a 239 MeeGo Profile, but in this case the application will be compliant with that Profile only. I would probably instead of shared libraries say 'services (shared libraries, d-bus services, etc)'. In this particular wording, there is nothing that blocks both vendors, or Maemo Extras from having shared libraries amongst components in a repository. Nor does it stop a vendor from having a closed source API which a compliant app would use which is maybe more of a problem. In the spec, there is already a hint of "Unstable public interfaces – may be used by compliant applications but forward compatibility is not guaranteed for next MeeGo versions." (lines 222-223). How does this (philosophically) differ from a 3rd party dependency? I propose we add a section about dependency solving in the spec. And that it starts with: "A MeeGo package can only be compliant if all it's dependencies can be found and retrieved and properly installed by all MeeGo reference devices during automatic compliance testing based on public repository information provided with compliance testing materials". And in this section try to counter 'bad' practices with regards to repositories. Last thing: Page 4, line 70-71: It shall use only external commands and other facilities described in this specification, whether for installation tasks or run-time tasks. A rather vague statement, which I read as that it should only use external commands or other facilities provided by the above API/Core packages and 3rd party packages that are compliant. Best regards, Carsten Munk _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
