[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [olpc-software] On installing software



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]