On 09/09/10 09:59, Marius Vollmer wrote:
"ext Ville M. Vainio"<vivai...@gmail.com> writes:
On Thu, Sep 9, 2010 at 11:14 AM, Andrew Flegg<and...@bleb.org> wrote:
That's why I'm proposing that the language in the spec recognises that
MeeGo-compliant packages can have a canonical location (e.g.
"repository X") and can depend on anything else in that repository.
This would not be completely accurate either. A manufacturer way want
to create a special repository for packages that apps in their app
store CAN depend on, and this is not necessarily the repository that
the sold applications are downloaded from.
Well, you will have a tree (or graph) of repositories, with dependencies
between repositories. This is what will happen, and if we want to do
it, we should have the tools for it and not let it happen purely
chaotically. (Remember, the Maemo repository mess? :-)
Or....
We have a central MeeGo build service for applications *and* libraries *and*
suites (like python).
Vendors can also apply to put targets there and applications can build against
any and all targets.
Any application that can build against approved projects in the MeeGo community
OBS, or just using MeeGo core, could be MeeGo compliant.
Approved projects must, of course, be MeeGo compliant and will naturally provide
a managed meego.com repo.
David
--
"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
