[maemo-developers] Considering /Opt And MyDocs In Your Packages

[From: Stefanos Harhalakis]

Hello,

Sorry for the broken threading. I just subscribed and the quote is from copy-
paste from nabble.

> ext Andrew Flegg <andrew at bleb.org> writes:
> 
> > Although a unionfs solution would be a bit more further dev on Nokia's
> > part, it will reduce the developer complexity and gives us a real
> > world solution now. I'm sure the community would help as well, with
> > patching/building/testing kernel modules (once again, Nokia should
> > realise there are clever technical people in the community who could
> > help design an optimal (= quick & good) solution if engaged at the
> > right time).
> 
> Yes, agreed.  Let's give this unionfs thing a shot.  I was previously
> arguing against it, but only as a long-term solution.  As a
> Fremantle-only hack, it might be better than the /opt hack.

After reading the whole thread I could offer you the following 
suggestions/thoughts:

1) /opt is not a good solution (tm). You can install large programs there 
(e.g. openoffice) but you should not install programs that other programs 
depends to there (e.g. libraries or command-line utils). This means that 
(according to what I understand from FHS) a program should not depend on 
another program in /opt.

2) You should consider making /usr/local a separate filesystem and suggest 
that programs use that instead of /opt. A system can work with most of its 
programs in /usr/local and you don't need of links, etc. I had a slackware-
based system which had almost everything in /usr/local for 8+ years and there 
weren't any problems at all.

3) If finally you use /opt/maemo, it may be better to suggest some hashing. 
For example /opt/maemo/foo could be in /opt/maemo/f/foo.

4) unionfs should be a very good and clean solution. I strongly suggest that 
you don't use UnionFS and you use AUFS. I had a lot of problems and oopses 
with the former.

5) If you use aufs, it will be a bit tricky to upgrade packages that are 
installed in / in a consistent way. For example, apt-get upgrade could end up 
installing things in the other partition. To solve this you should either do a 
chroot somewhere else (not-good) or use some voodoo magic :-)

6) If you somehow use aufs, it is possible to speed things up a bit. For 
example, you could:
* Create a union of the small (old) / and a X GB partition which is then 
mounted as /
* Mount the small (old) / as /oldroot as read-only.
* Prepend /oldroot/bin:/oldroot/sbin:/oldroot/usr/bin:/oldroot/usr/sbin in 
$PATH
* Perhaps use LD_LIBRARY_PATH with /oldroot/lib:/oldroot/usr/lib first.

This would make many of the things load directly from /oldroot while be able 
to fallback to the unionfs (which should not be that slow). Of course 
/usr/share won't be used directly, but I believe you can live with that.

7) I can report a success story from 5 computer labs with 120 PCs and more 
than 300 different students using aufs every day for two years now without a 
problem and AFAIK without a single kernel panic or oops. It is a little 
different configuration (union of a physical FS and a tmpfs) but it is a good 
test for AUFS.

8) You could reconsider (or explain) the need and usage of the internal memory 
(should I call it JFFS2 NAND?) completely. What is it's purpose? Clearly, it 
is not fit for the / filesystem if N900 is going to be used in a standard 
unix-way with non-nokia programs and upgrades. 

9) If you need this memory to just be able to provide "re-flash" 
updates/upgrades, then I cannot find a reasonable way to make this work 
without problems. Upgrading a library in /usr/lib (for example) could break 
programs. apt and dpkg are far better in handling this. However, this could 
always act as a fall-back solution (fail-safe), in case something breaks with 
the other memory.

10) If you want to use this memory for speed-up, then I believe there are a 
number of ways to do it.