Re: [Sugar-devel] Fwd: How about creating addons.gnome.org

[Jose Aliste <jose aliste gmail com>]

Hi Aleksey, thank you for your throughful mail.

On Sun, Aug 8, 2010 at 1:41 PM, Aleksey Lim <alsroot member fsf org> wrote:
> 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 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
>>
>>
>> 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
>
> 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.
>
I completely see the point. Thanks. Anyway, for now my idea is to have
a baby version of AGO, where non-compiled add-ons
can be maintained and all addons can be showcased. The problem of
distributing binaries, as you point out is much more difficult.
Anyway, I will be using the new version of AMO, which is written in
Django instead of CakePHP, so this should give a little more
flexibility.

> 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. 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.

Thanks for sharing this model. I can totally imagine a Gnome
Marketplace along the lines you nicely put here. Great work!


Cheers,

José


>
> [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
> _______________________________________________
> foundation-list mailing list
> foundation-list gnome org
> http://mail.gnome.org/mailman/listinfo/foundation-list
>