Opt Problem
(→Current problems / developer and packaging issues) |
(→Current situation: Add minutes from BOF) |
||
Line 12: | Line 12: | ||
* symlink: /opt/ -> /home/opt/ | * symlink: /opt/ -> /home/opt/ | ||
* OneNAND is faster (hard numbers? read? write? small blobs? big blobs?) | * OneNAND is faster (hard numbers? read? write? small blobs? big blobs?) | ||
+ | * Decisions were taken in a "what shall we do about /opt?" BOF at the [[Maemo Summit 2009]]. Minutes: http://lists.maemo.org/pipermail/maemo-developers/2009-October/021289.html | ||
= Some goals = | = Some goals = |
Revision as of 16:27, 23 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?)
- Decisions were taken in a "what shall we do about /opt?" BOF at the Maemo Summit 2009. Minutes: http://lists.maemo.org/pipermail/maemo-developers/2009-October/021289.html
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?)
Current problems / developer and packaging issues
This should be a list of current problems developers are experiencing related to optification:
- Symlinks take up space in the rootfs. This may become an issue if there are lots of them.
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.
Applications are made relocatable and installed to /opt
- Relocatable applications can move everywhere without breaking.
- No symlinks get scattered over the rootfs (symlinks take up space, too).
- Not all applications can easily be made relocatable.
- Requires more work by the programmer.
- May not be feasible for ports from an upstream source.
- Putting a startup script into /usr/bin setting up environment variables such as LD_LIBRARY_PATH can help.
- autotools-based packages can use --prefix=/opt/<packagename>.
- Python apps can make use of the __file__ module-scope variable to determine where they are installed (e.g. installdir = os.path.dirname(__file__)).
- Could be taken into account as an alternative to maemo-optify wherever feasible.