[Sugar-devel] Fwd: How about creating addons.gnome.org
Aleksey Lim
alsroot at member.fsf.org
Sun Aug 8 12:39:37 EDT 2010
On Sun, Aug 08, 2010 at 04:11:38PM +0200, Tomeu Vizoso wrote:
> Hi, the GNOME people are having an interesting discussion about AMO.
>
> Regards,
>
> Tomeu
>
> ---------- Forwarded message ----------
> From: Johannes Schmid <jhs at jsschmid.de>
> Date: Sun, Aug 8, 2010 at 15:28
> Subject: Re: How about creating addons.gnome.org
> To: Jose Aliste <jose.aliste at gmail.com>
> Cc: Tomeu Vizoso <tomeu at sugarlabs.org>, foundation-list at gnome.org
>
>
> Hi!
>
> > Also, there should be a clear distinction whether an addon is Gnome
> > approved (meaning it is reviewed, translated, probably hosted in the
> > gnome git somewhere) or the work of a freelance dev. Distributions are
> > welcome to keep packaging any of the addons, as they do now, but
> > normally the maintainer's cost of distributing 100 or more addons
> > would be too high (in my opinion). In this sense, I would love to have
> > an easy way of installing add-ons that does not require you to copy
> > files to some hidden directories. We should have a command line
> > gnome-addon install add-on-name, which will download and install the
> > add-on. That would be really neat in my opinion.
>
> While I would rather vote for a more complete "GNOME Appstore" solution
> in the far future (possibly based on OpenSuSE build service), some
> points to note:
>
> * This will only work for scripted plugins Python, Javascript, Ruby
> * All compiled languages will suffer depedency problems
> * It would mean that we install executable things into the user's home
> directory. Some admins might not like this though of course mozilla does
> the same. Security is an important point here.
>
> It is also a rather huge maintaince burden to check that the plugin
> works with the installed version of an application.
>
> But nevertheless, go for it if you have the time, it sounds like a good
> idea! Especially for the upcoming gnome-shell addons it could be a
> perfect place.
>
> Johannes
I can share my own experience in code sharing case.
There is a problem w/ AMO. AMO, as filesharing tool, works well only for
one-file bundles w/ anyarch data, trying to reuse AMO for not trivial cases
like binaries, e.g. different ABIs etc., sound overkill for AMO.
Right now, I'm working on different model - Zero Sugar [1].
The core things are:
* everything starts with spec file of the package - recipe file [2]
* it will be possible to local launch application only having this spec file
and sources tarball/vcs-checkout (in noarch case, or build application
locally and start it)
* keeping in mind variety of users environments and things like ABI
breakages (or even different build flags on different distros), it
would be useful to just build application in this particular
environment. So, using [2] recipe file, on patched OBS (in progress),
it will be possible to create native packages for bunch of deb/rpm
distros. It sounds like meta packaging but it is not [3].
* The important thing, installing applications from OBS repos is not
primary distribution method (it will work fine in case of centralized
repo of applications on OBS, but attaching repositories from
individuals(in my mind, regular behaviour in sugar ecosystem), i.e.,
from home projects on OBS, will be really overkill). The first
distribution method will be 0install [4]. So, OBS will create not only
native packages but 0install feeds as well (for nonarch applications,
only 0install feeds, for binary based, 0install will reuse native
packages).
* 0install is/should-be fully integrated into GNU/Linux distributions
ecosystem e.g. it is not about creating yet another distro, 0install
will reuse PackageKit to install already packaged software.
* OBS will be used as only one place for all file sharing/packaging stuff.
Sites like AMO will be used only as catalogs (users driven, e.g.,
reviews, ratings etc.) of applications - they will contain only
0install links (of files stored on OBS). Even more, OBS will be auto publish
info about new versions/packages on AMO.
[1] http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar
[2] http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification
[3] http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/Native_Packages
[4] http://0install.net/goals.html
--
Aleksey
More information about the Sugar-devel
mailing list