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

Contents

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

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.
Retrieved from "https://wiki.maemo.org/Opt_Problem"