Hi, > 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 installed. 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. Martin _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
