On Fri, Sep 03, 2010 at 04:59:37PM -0600, Wichmann, Mats D wrote: > There's a rough early version available on > http://wiki.meego.com/Quality/Compliance Thanks!
Just went through it, here are a few comments: - 70-71: "It shall use only external commands and other facilities described in this specification, whether for installation tasks or run-time tasks." It should be allowed to use commands / facilities provided by third-party packages it explicitly depends on. I think that's the intent anyway based on other parts of the document. - 106-109: "System implementers MUST use the source code of the MeeGo 1.1 Reference Implementation and SHALL NOT replace or omit Core or Profile components." There are cases where a vendor might want to substitute equivalent (read: identical API & ABI) components to take advantage of specific platform features. Some examples of this might be codecs that run on a DSP, hardware-accelerated SSL engines and so on. The substitute's licence should also match the reference implementation's to avoid unintentional issues with run-time linkage etc, but otherwise I think this should be allowed. - 175-176: "Application shall be installed to /opt/packagename/ and /var/opt/packagename/ directories." That's fine for GUI apps that are launched via .desktop files, but a bit problematic for libraries (should be in some location ld.so knows about) or command-line tools (should be in the user's $PATH). In both cases it would be a bad idea to keep growing the search paths for each installed package. If the actual files need to be stored in particular places for partition sizing reasons at least symlinks to them in the usual predictable locations should be allowed. - 3.4 Interpreted languages IMHO the location of the site/vendor trees should also be standardised here. Makes packaging extra modules unambiguous, plus similar considerations as above. L. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
