[olpc-software] On installing software

[David Zeuthen]

Hi,

So Mike Hearn had some interesting ideas a week or two back on this and
after some thinking about it a bit and talking to Dan Berrange, this is
what I would like to propose. It's a slight adaption of some of the
ideas that were raised on this list; a lot of credit goes to Mike Hearn
for the ideas

(I assume readers wanting to reply have read all the relevant threads on
this list so I will keep the description of my proposal to a minimum)

(Names of users and programs may be changed; this is just a proposal)

LaptopSoftwareManager
---------------------

 1. Have a system user 'laptopsoftware'

 2. On boot up mount /usr/local on tmpfs and make it world-readable but
    only writable for user 'laptopsoftware'

 3. Write a system-level daemon /usr/sbin/LaptopSoftwareManager that
    listens on the org.laptop.SoftwareManager D-BUS service

 4. Start LaptopSoftwareManager on bootup; make it run unprivileged as
    the 'laptopsoftware' user

The LaptopSoftwareManager service will do the following

 - It watches for AppDir's in /applications and /media

     /applications/Gimp V2.2.app/
     /applications/Gimp V2.3 beta.app/
     /media/Some Disk/XYZ Math Teacher.app/

   and emits D-BUS signals when it detects new software, e.g.

     org.laptop.SoftwareManager.AppDirAdded   with
      string=<app name>

     org.laptop.SoftwareManager.AppDirRemoved   with
      string=<app name>

 - Have a white list of AppDir's that are OK to install, maybe just
   a list of dirs that are OK, e.g. '/media/Some Disk/Learn Danish V2'

 - On start-up symlink all contents of all AppDir's on the whitelist
   into /usr/local

 - Emit signals when an AppDir is fully symlinked, e.g. fully installed

    org.laptop.SoftwareManager.AppDirInstalled    with
     string=<app name>,
     string=<app location>

 - Provide a D-BUS interface with a method for the desktop bits to
   "install software", e.g. to say app '/media/Some Disk/Learn Danish
   V2' is OK to be installed. 

    org.laptop.SoftwareManager.InstallAppDir (string appLocation)

   This method would simply put '/media/Some Disk/Learn Danish
   V2' on the whitelist and then symlink the appdir into /usr/local
   and then emit the org.laptop.SoftwareManager.AppDirInstalled signal
   on completed installation. It would throw exceptions such as

    - DependencyNeeded
    - FileConflict

   etc.. We would have to figure this out along the way...

   Specifically we can use PolicyKit to auth if we want, e.g. the
   desktop bits would ask

      +-----------------------------------------------+
      | Do you want to install the application "Learn |
      | Danish V2"? You need to enter your four digit |
      | pin to continue.                              |
      |                                               |
      |  Pin: ____                                    |
      |                                               |
      | -> More information on "Learn Danish V2"      |
      |                                               |
      | [Cancel]                            [Install] |
      +-----------------------------------------------+

   Specifically the desktop bits would pop this up in response to the
   org.laptop.SoftwareManager.AppDirAdded D-BUS signal

   Of course, it begs the question if there is a pin code / password
   on each account. Just for ensuring that no malware is installed
   by other apps this might be one good reason to do so. Or maybe not,
   I don't know at this point...

   There would be other useful methods on org.laptop.SoftwareManager
   so you could write an app browser; you could ask for dependencies,
   list of installed software, list of uninstalled software, how often
   software is used etc.

SYSTEM CHANGES NECESSARY
------------------------

The only thing we need to change is to make system-packaged software
look in /usr/local too. 

For example, this includes making D-BUS look in the
directory /usr/local/share/dbus-1/services as well as the canonical
upstream location /usr/share/dbus-1/services. I think we should be able
to get D-BUS upstream to accept this. Other things like

 - fonts
 - hal device information files (maybe not)

and others come to mind.

PACKAGING
---------

The proposal relies on AppDir's, that is, a collection of software
packaged up in

 Application Name.app/usr/bin
 Application Name.app/usr/share
 Application Name.app/etc

which is packaged to be installed into /usr/local. We probably also need
meta data about the package, suggest to put this in 

 Application Name.app/META-INF/...

where we would need things like dependency information etc. For
distribution probably the Applicaion Name.app.tar.gz format would be
used...

Yes, this is "just another packaging format"... As such we need tools to
build such packages and figure out dependencies automatically etc. Maybe
the stuff from autopackage or even RPM can be reused here?

What do you think?

     David