[olpc-software] On installing software

[Mike Hearn]

David Zeuthen wrote:
> Yea, names are difficult to choose, I'm not attached to the name
> LaptopSoftwareManager but I have a slight affection for StuddlyCaps and
> all the die-hard UNIX people hate me for it :-). Naming is just
> difficult.
>   
I don't mind StudlyCaps though I agree it's a bit non-unixy :) I was 
thinking more of dropping the laptop part, otherwise if one day it ends 
up being used on desktops that really _will_ look weird.
> Because
>
>  1. /usr is on flash, we don't want to wear that out with writing
>     symlinks
>
>  2. /usr and / will probably be mounted read-only and we really never
>     want to modify these as it makes core OS upgrades harder (this is
>     where we want to ship binary deltas)
>
>  3. I like that a reboot completely rebuilds the forest of symlinks;
>     it's sorta inline with the appliance thinking: "if the damn box
>     doesn't work, just turn it off and it starts working again" [1]
>
> [1] : Sure, LaptopSoftwareManager should be able to work on /usr and
> have enough brains to start with a target of existing symlinks...
>
>   
Good point. And it could be trivially changed if redeployed elsewhere in 
future I guess, but you are right that /usr/local makes sense for OLPC.
>> But there is not a lot of software on OLPC.. sure, for usage on other a
>> normal Linux distribution this might not be the case... but I'm pretty
>> sure you can get those "look in /usr/local too" patches upstream, don't
>> you?
>>     
Historically getting that sort of problem fixed was tough, but that is 
because most developers don't see it as a priority. OLPC has much more 
weight than I do, so it'd be easier.
> [2] : I really like Fedora Extras. I do. It's wonderful and useful. But
> I think that ideas like AppDir packaging against a known platform makes
> a ton of sense too.
>   
Yes, I know that feeling :) In fact a long time ago when autopackage was 
first being designed a distributed DNS style network to enable the 
"apt-get install <packagename>" type UI was a big part of it. In the end 
that never got written, but a tree of QAd packages accessible by typing 
in its name would be a great thing, and doesn't fundamentally require 
centralised repositories.
> Yea, it's very very tempting to say just that, cf. that we have plans to
> provide an ABI stable platform as I mentioned here
>
>  https://www.redhat.com/archives/olpc-software/2006-March/msg00107.html
>
> I say we just do that... sure, we trade some efficiency and bandwidth
> for the very desirable goal of not having dependency checking. And
> specifically for OLPC I don't see a lot of apps installed on the laptops
> sharing libraries and frameworks anyway...
>   
IMHO it's better to have the features and tell people not to use them, 
than risk ending up needing it and not having it. For instance, consider 
the case of a Macromedia Director equivalent being produced for 
educational software after OLPC is launched .... carefully controlled 
and with due consideration to the cost dependencies need not be hell. 
The problem we have on Linux is people consider them to be free and use 
them for everything, all the time.

An abuse of dependencies could also be done for language packs - at 
least the autopackage apis would let you download+install the right 
language pack from the net very easily.

That said I think you're right that nearly all apps should install with 
no dependencies outside the platform, or at least, that's what we should 
aim for.
> So... would I be able to take an autopackage and expand it into an
> AppDir for this LaptopSoftwareManager we are discussing? Because, if
> that's the case then it's great and we are a long way already...
>   
It can be done today. Edit /etc/autopackage/config and read the comment 
above the autopackage_default_prefix variable .... it can be set in such 
a way that every program installs to its own location. It's not that way 
by default because there's no daemon around to symlink things back 
together :)

Right now autopackages are made relocatable by using a little C file 
that is statically linked in but this involves modifying the software 
and is a pain. I've written a kernel patch to add a /proc/self/exedir 
symlink so any UNIX program can be made relocatable by doing  
./configure --prefix=/proc/self/exedir/..    - this has been tested on 
Gaim 2 and works fine. Andrew Morton has said it needs to gain mindshare 
before he'd accept it though, so I need to figure out how to get that :)

thanks -mike