On 14/09/10 23:34, Skarpness, Mark wrote:
On Sep 14, 2010, at 2:09 PM, David Greaves wrote:
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.
OK. What are these?
As I said. I cannot believe that they care if the code downloaded to install an
application uses 1 tcp connection or 2.
I *can* believe that they want to protect their device from using code
downloaded from "not my app store" - in which case policy is their friend (as
described later).
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.
OK. Why? I have nothing other than "not a good idea". Maybe you mean the points
later in the email?
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.
Yes. That would be MeeGo.com and a CDN. Again, not a hard problem at all. I'd
think you'd be thrilled to have a big bill in that situation!
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)?
This still doesn't fly even a little bit.
Anyone capable of asking and understanding an answer to this question should be
able to cope with the answers:
4010 + 4050 + 4400 + 400 + 445 (5 apps)
10 + 50 + 400 + 400 + 455 + 4000 (5 apps with 1 shared dependency)
I also think they'd be happier with the second answer.
If they don't understand the sequence of numbers then try them on this:
13305
5315
(smaller is better)
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)?
As an app-store owner; you have a policy. If you only accept apps that don't use
Surrounds then that's fine. I assume we are not mandating that app stores *must*
accept all applications submitted to them?
MeeGo of course should allow app stores who actually have the competence to
support dependencies to do so. Several design solutions have been proposed and
our 'reference' app store should have no problems.
My favourite is that the app store sends a dependency list to the application
manager and when the client side application manger confirms that all
dependencies are installed, the application can be downloaded. Seems like
another well understood solution (zypper/yum/apt)
A *huge* benefit of having MeeGo Surrounds is that we have *one* place where
this kind of shared application dependency needs to be looked for.
*PLEASE* listen to the hell that Maemo endured when they had a multitude of such
repos (commercial or community)
Could these problems be solved? Maybe...but they aren't trivial.
Nothing in this area is trivial. See above for solutions that aren't rocket
science either.
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
Good
- but
hmmm
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.
At what point do any of the commercial builders get impacted by allowing GPL
apps to use Surrounds?
Heck if LGPL libraries get into Surrounds then they smile as MeeGo gets richer
(and yes they need to understand the risk they expose themselves to at that point).
At this point I'd like to just to address a couple of comments in the whole
thread that hint at worries about "freedom" vs "pragmatic" - not just you Mark :)
From my point of view this is not a rant against closed code or trying to make
MeeGo 'more open'. This is software release engineering in an open source world
that has multiple application sources and the potential for painful conflict.
I want to see a solution that promotes MeeGo as superb place to develop
applications; I want even closed applications to have easy access to open source
components.
Also... it seems to me that MeeGo Surrounds and MeeGo Extras will exist anyway -
this is about whether they'll be labelled "MeeGo compliant" if they share code.
Or, whether the very first act of MeeGo.com towards the opensource developer
community is to effectively say "you're second class" and you can't be called
MeeGo compliant unless you work in isolation.
Heck.... I was on IRC today and a guy came to ask about porting a framework to
MeeGo ... he has no GUI.
http://zeitgeist-project.com/
The *WHOLE POINT* is to allow other gui apps to use this framework to
participate in lifeblogs - streams of events about what music tracks you play,
where you are, what web pages you're looking at as you listen, what book you're
reading.
'You' just canned it. The whole concept is second class... apps using it are not
worthy of being MeeGo compliant.
anyhow... onwards... it's gone 1am and I'm rambling...
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...
Yes. That's right. It's called 'sharing' ... open source economics 101.
One crucial thing is that you are not *obliged* to do this. We are not asking
that you mandate that *all* packages *must* use a module if one is provided in
MeeGo Surrounds (as a true distro would).
We are asking that you *permit* sharing...
The other crucial thing is that you do not "pass the problem on to someone
else". You "enter into the community and contribute to the quality of the code
with someone else".... just as we hope will happen with core MeeGo.
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
Yes... it's called Surrounds.
And that's a serious statement that cuts both ways.
I recognise that 'we' must do whatever it takes to make it acceptable.
I would like you to consider what we need to do to make it acceptable.
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.
--
"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
