Hi Aleksey, thank you for your throughful mail.
On Sun, Aug 8, 2010 at 1:41 PM, Aleksey Lim 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
>> Date: Sun, Aug 8, 2010 at 15:28
>> Subject: Re: How about creating addons.gnome.org
>> To: Jose Aliste
>> Cc: Tomeu Vizoso , 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 sharin
