Allow me to invert this email and suggest some prioritisation.
On 18/09/10 01:09, Skarpness, Mark wrote:
> What we have been discussing on this thread is the guidelines themselves...
Good point ... and I have made one of the very few concrete proposals for
wording in this thread ... and AFAICS it hasn't been even commented upon.
Perhaps you'd care to go back to that?
As I say... my objective is to permit (not mandate) MeeGo compliance for
applications developed using the open-source development model which tends to
favour componentised applications with cross app shared components.
First of all, could you and Arjan (as the main objectors) clarify if this is a
worthy objective for MeeGo?
If it is an objective then I'd like to see us work to achieving it. If there are
unsurmountable technical issues then... OK; lets back off until a solution can
be found.
My compliance wording proposal is:
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.
Please comment.
Some irc conversation raised a few points:
* What does compliance promise
* Is compliance verification implicit
I am assuming, respectively:
* If you _install_ a compliant app then it will work
* The on-device installer is not going to enforce or even verify that an
application is compliant
The first point means that the installer tool must verify dependencies before it
installs an app; if the dependency installation succeeds then the application is
installed. This will only affect users and applications using external dependencies.
I hesitate to mention some technical thoughts as they are easy to critique
before we address the main issues above; however:
I would anticipate that installation from an app store could streamline this
process through negotiation:
"this app needs X=<ver>,Y,Z"... "OK, can meet"..."here's the app"
I also assume the app store will need to know the profile of the device in order
to satisfy small issues like making sure compliant x86 packages don't go to an
ARM device ;)
(To paraphrase Andrew Flegg... MeeGo compliant doesn't mean you have to run
qemu!)
This profile *could* include capabilities (enabled repos) which *could* be used
to limit the users exposure to apps that they can run.
Below is some further reasoning:
On Sep 17, 2010, at 4:43 PM, Will Marone wrote:
On 9/17/2010 12:02 PM, Quim Gil wrote:
On Thu, 2010-09-16 at 12:13 +0200, ext Jeremiah Foster wrote:
Supposing I wrote software and made it available via Extras/Surrounds, why
is my app being there grounds to disqualify it for "compliance" even if it
meets the guidelines fully? Certainly that's insulting to the author and
implies things about their software that may be completely false.
It's not. This has never been suggested by anyone.
If your app meets the guidelines fully - then it will be qualified for
compliance.
Will, here is where the potential discrimination against open-source arises.
Clearly there is no discrimination against the license per se; I am well aware
of that.
*However* .... there *is* a discrimination against the model (well, there will
be if the draft is modified as has been suggested).
Open source apps *tend* to have external dependencies.
Closed source apps *tend* not to.
If I look at a couple of apps on debian:
skype .... 19.2Mb
twinkle .. 1.7Mb
Guess which uses libspeeex and co?
Another example: if http://zeitgeist-project.com/ gets into Surrounds (they came
onto irc to discuss porting to meego) then that framework cannot be built upon
by MeeGo Compliant apps.
You can distribute it via Extras / Surrounds or whatever other
mechanism you choose.
I feel a few people misinterpreted a statement I made earlier:
I think we need to achieve 2 things:
* permit the open-source development model to work for compliant applications
..[snip]
I try to be careful with my words.... I *DID NOT* say
"permit open-source compliant applications"
So I realise we can make and distribute compliant apps.... we just can't use the
"best practice" method that OSS tends to favour and still call them compliant.
Anyhow... that is why I feel all this is important.
Those building devices get to choose which sources of
applications they make available on their device (i.e. just because you have
a compliant app does not mean every device is required to make it available
to the end user for installation - though if you have a good app, I would
expect everyone to want it :-)
YES ... every time you say something like this Mark I feel we are getting closer
to a solution :)
"Those building devices get to choose which sources of applications they make
available on their device"
ie... policy can override "mere compliance" already.
A user can't expect that their "device [will have] it available [snip] for
installation"
I see refusing to install an application that relies on Surrounds (because it's
not "enabled") is just another policy restriction.
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
