-----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 <[email protected]> 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----- _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
