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



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.

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.

[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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]