[MeeGo-dev] Meego spec - for comment

[David Greaves]

On 16/09/10 19:09, Skarpness, Mark wrote:
>> If the 2nd differs because it "depends" on the first one then what
>> additional burden exists?
> As we have discussed repeatedly - the burden that a device must provide a way
> to install the second app (or dependency).

Can we agree our goals?

I think we need to achieve 2 things:
* permit the open-source development model to work for compliant applications
* define the spec in a way to minimise the imposed burden on vendors

Arjan, Mark : do you want to achieve this?

If we, as MeeGo, believe in the opensource "build on the work of others" and 
"co-develop shared components" ... then why do we prohibit the underlying 
development model that got us here?

What message does that send to the Vendors?

So I want to "leave the door open" for community developed apps that build upon 
the work of other compliant apps to be accepted (optionally!) into app stores 
and be of equal standing to statically-linked apps.

To do this they *must* have a compliance label.

You need a spec that ensures that apps are widely deployable and reliable?

We have established that vendors need not provide a way to install every 
compliant app.

Given that vendors can prohibit some compliant apps then the spec should allow 
them to prohibit compliant apps that depend on unavailable compliant libraries.

How could we word this to say that?

Something around 157 where it says Applicaiton packages SHALL "require" (in RPM 
terminology) all system and third party comonents ....

add:

Applications *MUST NOT* require (in RPM terminology) packages that are not 
themselves compliant.
Applications that require (in RPM terminology) packages that cannot be provided 
MUST NOT be installed.

David

-- 
"Don't worry, you'll be fine; I saw it work in a cartoon once..."