Opt Problem

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

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.

Have a 2-5gb partition on the emmc for addon packages mounted to /usr/local or /opt

  • Most apps by default usually go there
  • for /opt store according to the FHS standard /opt/<package> and symlink to /opt/{bin,lib,share,...}
  • Having ld.so.conf and PATH set properly avoids all the symlink madness
  • Don't do symlinks for /usr/local|/opt - make it a real partition
  • Explain to people why they don't have full 32GB of storage - or use LVM on the eMMC to dynamicaly change the size as things get installed through some dpkg hooks or such - we do know how much it will take ahead of time so if there isn't enough storage do a resize(VFAT should be resizable with something like gparted maybe?) ext3/2 are both online resizeable (growth only!)
  • Requires a bit more work when packaging - make some defaults pre-set in SDK
  • All apps should use a normal usr layout underneath any path. Example: /opt/maemo/{bin,sbin,lib, etc...} same if it would be in /usr/local - works like GNU stow

store addon packages completely in /home/opt hierarchy

  • like previous solution but on the standard /home partition
  • very clean solution if speed advantage of OneNAND over eMMC turns out to be a myth
  • /etc and /var could be copied there as well and mounted to root using bind. 
This way OneNAND would only be changed be reflashes and
if /home is not mounted (e.g., by a keypress during boot) a standard system
could boot OneNAND only.

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.

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.

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.

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..
  • Against standard

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?

Use mount -o bind (or -o rbind)

  • Method: Do not use NAND for any additional data. Boot into standard image. Any additional changes made are only available after -o bind or -o rbind which are defined in /etc/fstab . Setup provides potential fail-over; if -o bind or -o rbind fails user gets into 'rescue shell' providing 1) recovery method 2) quick install to vanilla firmware without 3rd party utilities, networking, or computer (think: no network available, expensive roaming, no computer with fwflasher or Nokia Software Downloader available, ...)

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.

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.

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