[IAEP] [Sugar-devel] addons.sugarlabs.org is starting to work

[Jonas Smedegaard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Feb 18, 2009 at 08:56:41PM -0500, Luke Faraone wrote:
>On Wed, Feb 18, 2009 at 8:01 PM, Carol Farlow Lerche <cafl at msbit.com> wrote:
>
>> Why not provide a dependency declaration in the activity file which 
>> can be checked when the activity is installed?  It could inform the 
>> user that a particular package or library was needed.  I understand 
>> that different distros may package the dependencies differently, but 
>> it wouldn't be so bad if the user had to identify this at 
>> registration (if not an XO running a recognizeable distribution) or 
>> when using the activity.s.o site.  Then the checker could recognize 
>> which dependency declaration to use (or could announce "this activity 
>> has dependencies but your distribution hasn't been described" -- or 
>> words to that effect.
>>
>
>Because at this point, you might as well use a standard and well 
>supported format for packaging: either LSB packages (RPMs), or Debian 
>packages. (which, as I pointed out, both work on almost *every* 
>distribution) As I recall, the only argument raised against using one 
>of those formats was the administrative rights required to use them. 
>Since dependancy installation is not something most children can do, 
>administrative rights are needed, it seems, no matter what for some 
>hardware installations.

I agree that both RPM and DEB formats require root access, but I imagine 
some standard packaging format containing dependency handling could be 
(ab)used, as kids have no use installing broken packages anyway:

1) Check dependencies

2a) If all dependencies are satisfied, extract content

2b) If dependencies missing, fail non-root install


There are other problems in reusing packages across distributions, 
though. Examples:

* Python scripts are arch-independent, but ways to install them are 
distro-specific:

Debian (and derivatives) use a choice of 2 different distro-specific 
mechanisms to install at a custom place and symlink into the right place 
depending on the versions of Python installed.

Debian and its derivatives may not contain same versions of Python, and 
even if above mechanisms internally untie the packages from the Python 
versions, the dependency handling still requires the packages to declare 
explicit Python version.


Also, there are other problems using "classical" packaging formats at 
all:

* One of the main purposes of both RPM and DEB is to contain only stuff 
relevant at runtime, stripping source. Python scripts are both runtime 
and source, but gettext .po files are stripped from such packages. Other 
simpler packaging formats targeting embedded systems are even more 
aggressive, also stripping e.g. documentation files to minimize space.


I'd say that packaging is distro-specific, and that it would make sense 
to stay with the .xo format for your user installs.

It would make sense for me if that .xo format was extended to include 
Sugar-specific dependency hints, to make it possible for your user 
install routines to ask the Sugar environment about its own provided 
libraries and versions of them, independent on underlying distro.

Example:

A new "Speak" activity needs the new GStreamer-based speech-dispatcher 
and Sucrose at least 0.82.

1) "sugar-toolkit" provides ABI to query features, returning either null 
or version (major and minor number)

2) "sugar" declares that it provides "sugar" 0.82

3) "sugar-speech" declares that it provides "gst-speech" 1.0

4) "Speak" .xo declares that it needs "sugar 0.82" and "gst-speech"

To keep .xo hints as simple as possible, the versions are implicitly 
"...or higher". In other words features declared must be packwards 
compatible: if sugar 0.96 breaks backwards compatibility, then it no 
longer features sugar and should instead declare e.g. sugar2.

If Sugarlabs later choose to integrate the functionality of that 
GStreamer-based speech-dispatcher in core Sucrose then "sugar" 0.86 can 
declare both features "sugar" 0.86 and "gst-speech" 2 (assuming the new 
implementation is backwards compatible but adds a few new features too), 
and sugar-speech is no longer needed.


  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmdGPEACgkQn7DbMsAkQLiq5wCeJBL2cA2i/V25oKUMt0A8m0Xa
hBYAniPdzgkGCB3GFw4HaIhGgv+IQMrO
=aCSU
-----END PGP SIGNATURE-----