Opt Problem
(→The /opt Problem) |
|||
| Line 2: | Line 2: | ||
There is not enough space on root to fit all applications, therefore additional partition has to be used. But just how? | There is not enough space on root to fit all applications, therefore additional partition has to be used. But just how? | ||
| + | |||
| + | There is a section in the Maemo 5 Developer Guide explaining the basics: | ||
| + | http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing/Installing_under_opt_and_MyDocs | ||
= Current situation = | = Current situation = | ||
Revision as of 04:39, 16 October 2009
The /opt Problem
There is not enough space on root to fit all applications, therefore additional partition has to be used. But just how?
There is a section in the Maemo 5 Developer Guide explaining the basics: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing/Installing_under_opt_and_MyDocs
Current situation
- 256MB OneNAND chip: bootloader, kernel, root (ubifs - with compression)
- 32GB eMMC: /home ~2GB (ext3), /home/user/MyDocs ~29GB (vfat), swap 0.7GB
- symlink: /opt/ -> /home/opt/
- OneNAND is faster (hard numbers? read? write? small blobs? big blobs?)
Some goals
- Firmware should be flashable.
- Should not break applications.
- One should be able to install more that 256mb worth of software.
- Standards compliance, less need to make uncompatible quirks.
- A fix should be doable after shipping (before shipping, probably not?)
Possible solutions, even the bad ones
Use aufs/unionfs to overlay OneNAND root with eMMC filesystem.
- This could be partial overlay, for example only /lib and /usr.
- Could keep essential libraries on OneNAND so they would work faster.
- Has anyone measured the speed penalty for aufs/unionfs usage?
- Is it faster or slower that moving root to eMMC?
- Might be difficult to have new programs to benefit from faster OneNAND.
Move root from OneNAND to eMMC and combine with /home to create a new root
- How much faster OneNAND is? Numbers?
- Can flasher flash on eMMC?
Require that applications have --prefix /opt
- Could be forced by a buildbot.
- Should not break anything.
- Programs would not benefit from faster OneNAND.
- Requires at least additional $PATH setup?
- Programs which have hardcoded paths (ugly code) break.
- Could additionally symlink files from opt to root.
- Just reminds me of 770's /var/lib/install..
Hack with --datadir, --libdir etc. through debian/rules
- Could be forced by a buildbot.
- Should move most of the big lumps on larger media if there are some.
- Works at least with packages with configure.
- Requires at least additional $LIBDIR setup?
- Programs which have hardcoded paths (ugly code) break.
- Could additionally symlink files from opt to root.
During packaging move all files >500kb to /opt and symlink to root
- Optify is basically this.
- Install is not slowed down, work is done when packaging.
- Some packages break when replaced with symlinks. How to prevent - hack on hack?
- A buildbot could force this to debian/rules automatically.
After install move all files >500kb to /opt and symlink to root
- Could be done at background after install or with post-install hook.
- There might not be enough space on / even for install.
- Install is already slow, could make it even slower.
- Some packages break when replaced with symlinks. How to prevent - hack on hack?
- Uninstall might be messy, some post-remove magic needed.
Turn the problem around, pivot the root with /opt
- After pivot /opt would be root and old root would be /opt. Symlink the old root contents to new root would make those available.
- Can the base system dependencies handle this?
- Can Nokia created software handle this?
- Could this work? If so, then all additional packages would install directly on eMMC.
Chroot install in /opt, symlink to where it belongs
- A Bit like stow.
- Maybe somebody can see something good in this?
- Difficult hack.. would need all the tools etc to be visible in the chroot.