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:
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?
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.
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?
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.
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
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.
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
[email protected]
http://lists.meego.com/listinfo/meego-dev
