On Sep 14, 2010, at 2:09 PM, David Greaves wrote: > sorry - the quote attribution seems messed up. >> On Sep 14, 2010, at 10:22 AM, Alexey Khoroshilov wrote: >> On 14/09/10 20:19, Skarpness, Mark wrote: >> On 09/13/2010 11:53 PM, Quim Gil wrote: >> On 09/13/2010 12:04 PM, ext Alexey Khoroshilov wrote: > > >> Just to clarify, > <snip> >> all API that MUST be installed by default in >> any MeeGo compliant device. Other API -- any other API that may either be or >> not be available on a MeeGo device. > So that's a device. OK. I think that's clear. > >> "A MeeGo compliant app runs on any MeeGo compliant device". If we dilute this >> we are opening a Pandora's box. >> >> That is a good definition. But what is about installation time issues? We >> still have no clear agreement should MeeGo compliant applications be allowed >> to be separated to several packages or not. If yes, the next question is >> should MeeGo compliance specification say anything about dependencies >> resolution process or should it be left out of scope? > OK ... so you raise this but then just say: Actually that question was raised by Alexey and then I answered...(sorry, the quoting got messed up...) > >> In my view, a MeeGo >> compliant app should be provided in a single package with no external >> dependencies that are not satisfied by a MeeGo compliant device. > > because: >> Allowing >> applications to have arbitrary external dependencies that are resolved at >> install time adds a great deal of complexity and uncertainty for a device >> manufacturer (substitute "MeeGo software stack provider" for "device >> manufacturer" if you wish). > What on earth has it got to do with the _device manufacturer_ whether this is > in > one package or two? For someone deploying a commercial device based on MeeGo (handset, tablet, TV, ...) - this does matter and brings a lot of requirements. > > It _is_ a problem for the MeeGo distro (which will be on the device). The > MeeGo > distro would need to provide complex dependency resolution tools - like yum > and > zypper. So, barring some gui niceness, that's done. > > So the 'problem' is tremendously well understood and totally solved. yes, I understand that it's technically possible to do this. That doesn't mean it's a good idea.
> >> I want to create a simple "contract" between the device manufacturer and the >> application developer: the device manufacturer promises to provide a defined >> set of packages and the application promises to install and run correctly >> using only those packages. > OK ... > So you're essentially saying it matters if I use 2 tcp connections to > download > the "collection of code that will run" rather than 1? > > I'm not sure who this matters to or why? It actually does matter to those deploying devices. A few examples of why: If compliant apps are allowed to have external dependencies - then someone has to pay to host and maintain those dependencies so they are available worldwide to many millions of devices. As someone building a device - how do I know how much storage is required for the OS in order to run compliant apps (as Arjan pointed out earlier in the thread)? If I'm running an app store, how do I make sure that everything is delivered correctly before I bill the user (since as the app store provider, I may not be supplying the dependencies)? Could these problems be solved? Maybe...but they aren't trivial. > >> The MeeGo Extras stable repository would contain apps tested to work on top >> of official MeeGo releases. No "compliance" word needed: they are "extras". > I disagree. As a developer of a GPL application I want my work to be > perceived > as "just as valid" as a commercial "compliant" application. > > Of course, if being "compliant" doesn't matter then this whole debate is void. > > 'Extras' (or whatever we brand it) *must* have the option to be compliant. > Absolutely - but MeeGo also needs to meet the needs of people building commercial device products and applications - so the rules for how you build and distribute that GPL application may be a bit different then they would be for a "standard" Linux distro. >> From compliance perspective, the question I concern myself with is: What >> should we recommend to an application developer who would like to use, for >> example, a python module that is not a part of the Platform API. In this >> thread there were proposed the following non-mutually exclusive >> recommendations so far: 1. You can consider the module as a part of your >> application. In this case you have to add it to your RPM package, install to >> application specific location, update it along with the application, etc. I'm >> in favor of this approach. > In stark contrast to every other distro out there. > > You are aware that you are asking developers to undertake a significant > additional maintainance and test burden with packages that are just not > designed > to be installed multiple times (eg config files in /etc) > > This does not make MeeGo an attractive target for developers. > >> 2. You can extract the module to a separate >> package and make your application dependent on that package. > That is not what happens. > > A better statement would be: > "You identify a module that uses several other open source modules that make > writing your code much easier" do you: > > a) add a single "Require" and "include" statement, ship and smile while you pass the problem on to someone else to make sure this actually works correctly with a device deployed to an end user... > > or > > b) take on the re-packaging, maintainance and security update burden for > every > single package in the chain of dependencies and ensure that you work with > other > unknown parties to ensure conflicts with multiple installs don't happen. also not good...things that are really widely used by applications should be added to the MeeGo core OS...but that's probably not good enough...we need a better solution > >> In this case, >> 2a. you can keep the module in your private namespace. Then you have to >> install it to your private location and update it yourself. You can share the >> module with other applications as you wish. > How can you share it with other applications? It would not be part of the > core > distro or any community distro. > >> 2b. you can share the module >> using the MeeGo Extras. > I'd like to ask people at this level of technical debate to use better terms. > Extras is an app-store > Surrounds[1] is a proposed name for a community managed shared code repo. > >> In this case it will be installed to public locations >> (like /usr/lib/python), but you should be aware of the following risks: - >> MeeGo Extras version can be overwritten by a vendor specific package on some >> devices (hopefully it will be compatible with Extras' one); > I'm not sure how this happens; I have mentioned that there should be a > mechanism > to allow migration between Core and Surrounds. > >> - MeeGo project >> does not provide any guarantee regarding stability and QA of MeeGo Extras >> packages further to MeeGo Extras community efforts; > But as a developer working with the community you can and should participate > in > this process - one thing we can say is that, by definition, it's likely to be > a > lot less work than maintaining your own version. > > >> - you have to follow >> changes in MeeGo Extras and test/update your app appropriately. > And part of MeeGo Surrounds processes needs to cater for this. > > David > > -- > "Don't worry, you'll be fine; I saw it work in a cartoon once..." _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
