On 09/13/2010 11:53 PM, Quim Gil wrote:
On 09/13/2010 12:04 PM, ext Alexey Khoroshilov wrote:
It sounds reasonable to me. Keeping all non-Core dependencies within
each application package would be the best and the most clean technical
solution of many issues, but it has some drawbacks (as it was discussed
in the thread):
- potential conflicts of single instance services;
This is why having MeeGo Extras within the MeeGo project as a reference
is more useful than having no reference at all. The Extras maintainers
must follow the MeeGo unstable releases and make sure the packages
maintained there just work. If Vendor X needs to provide packages that
are not part of the official MeeGo, their default reference will be
MeeGo Extras
- wasted disk space that is essential for some devices;
Having MeeGo Extras as a reference helps resolving the conflicts and
duplications there, instead of just pushing lazy/ugly hacks bloating
users memory space
- extra security risks in view of the fact that all instances should be
updated by all providers independently;
Again, this enforces everybody's interested on having a MeeGo Extras QA
process where anybody can look and report issues. And where a system is
in place to demote packages, push updates, etc.
- lack of tool support that is required to make the approach easy-to-use
for application developers.
If an app developer is looking for the easy-to-use then they must go for
the official APUIs and SDK, which will probably include an easy way to
publish to the AppUp, Ovi, etc.
Developers that decide not to go through the official route can still
find a reasonably easy process to get their packages at MeeGo
Extras-devel, and from there promoted through the QA process. Hundreds
of app developers have done this already at
http://wiki.maemo.org/Uploading_to_Extras-devel
The MeeGo Community OBS might make this process even simpler.
Actually, I meant here that many problems with the bundled approach can
be addressed by using proper tools support.
For example, disk space waste issue can be addressed by BTRFS
deduplication and copy-on-write features.
Arjan, is it possible?
Also MeeGo SDK could contain tools for converting MeeGo Surrounds
library packages into components of application bundle, tools for
semiautomated updates of that libraries, etc. In this case, compliance
burden on app developers who are not happy with Platform API would be
decreased.
Alexey Khoroshilov,
ISPRAS / Linux Foundation
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev