[maemo-developers] Considering /opt and MyDocs in your packages

From: Martin Grimme martin.grimme at gmail.com
Date: Thu Oct 22 10:16:48 EEST 2009

> It would be helpful if you could provide instructions on how to install
> apps directly into /opt without changing too much of the packaging
> stuff (remember, some package maintainers have to keep the Diablo
> version and maybe even a Linux Desktop version up to date as well,
> so anything that avoids big differences in packaging/code helps here).

This depends on how you have setup your build-system. With GNU
autotools, running configure.sh with --prefix=/opt/<packagename> would
be a way, but you
have to take care that the application icon, .desktop file and D-Bus
service activation description still get into the rootfs.
If you're using a simple Makefile instead if autotools then you have
full control already.
Relocating Python apps to /opt should be pretty simple. I do so by
installing into /opt/<packagename> and putting a symlink to the
executable module into /usr/bin/ (although this is not really required
if the path in the D-Bus service activation description already points
to /opt). If I need to find out about the installation path of my
application, I read the __file__ variable which in every Python module
points to the file path of that module file, so I know where to find
my graphics and other data files, no matter where my application got
For C applications you may experience other problems such as not
finding .so files.
A way around this could be replacing the executable in /usr/bin with a
shell script setting up the LD_LIBRARY_PATH variable for your app
correctly. XDG_DATA_DIR can be specified by environment vatiables,
too, IIRC.

> I think a subsection on this wiki page would be ideal:
> http://wiki.maemo.org/Opt_Problem

I fully agree. Developers should be made aware that maemo-optify is
not always the best way to move stuff to /opt.
If I find some time this evening I'm going to make a start on the wiki page.
There are some more caveats I stumpled upon, e.g. putting application
graphics other than the app icon into /usr/share/icons results in a
huge icon cache file.
These issues should all be covered on the wiki page IMHO.

> Adding "maemo-optify" as build-depends and to debian/rules is just
> simpler and more straightforward than doing more intrusive changes.

Yes, nothing against it. But developers should be made aware of the
problems that may arise and that alternatives do exist. For porting
stuff with hardcoded paths optify might still be the only feasible
way, especially for developers without deep Linux experience.

More information about the maemo-developers mailing list