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..."
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
