[IAEP] [Sugar-devel] addons.sugarlabs.org is starting to work
dr at jones.dk
Thu Feb 19 03:31:46 EST 2009
-----BEGIN PGP SIGNED MESSAGE-----
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
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,
* Python scripts are arch-independent, but ways to install them are
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
* 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.
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 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)
-----END PGP SIGNATURE-----
More information about the IAEP