Hi Aleksey, thank you for your throughful mail. On Sun, Aug 8, 2010 at 1:41 PM, Aleksey Lim <alsr...@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 <j...@jsschmid.de> >> Date: Sun, Aug 8, 2010 at 15:28 >> Subject: Re: How about creating addons.gnome.org >> To: Jose Aliste <jose.ali...@gmail.com> >> Cc: Tomeu Vizoso <to...@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 > _______________________________________________ foundation-list mailing list foundation-list@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-list
