Re: [Sugar-devel] Fwd: How about creating addons.gnome.org
- From: Aleksey Lim <alsroot member fsf org>
- To: foundation-list gnome org
- Subject: Re: [Sugar-devel] Fwd: How about creating addons.gnome.org
- Date: Sun, 8 Aug 2010 17:41:47 +0000
On Sun, Aug 08, 2010 at 04:11:38PM +0200, Tomeu Vizoso wrote:
> Hi, the GNOME people are having an interesting discussion about AMO.
> ---------- Forwarded message ----------
> From: Johannes Schmid <jhs jsschmid de>
> Date: Sun, Aug 8, 2010 at 15:28
> Subject: Re: How about creating addons.gnome.org
> To: Jose Aliste <jose aliste gmail com>
> Cc: Tomeu Vizoso <tomeu sugarlabs org>, foundation-list gnome org
> > 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:
> * 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.
Being AMO maintainer on http://activities.sugarlabs.org/,
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. In any
case it will be just a hosting for files, all releated issue like
depedencies is not handled by AMO.
Right now, I'm working on different model - Zero Sugar .
The core things are:
* everything starts with spec file of the package - recipe file 
* 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  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 .
* 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 . 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
* 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. It will
hande not only 0install depedencies but native packages as well
(in any case any package within 0sugar is an entyty on OBS, some of
these entities will be aliases for native packages, other will be
built on OBS).
* 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.
] [Thread Prev