On Thursday 10 September 2009 07:53:37 Andrew Flegg wrote: > The use of /opt/_package_/ on Diablo, Fremantle, Mer, Ubuntu is > entirely concordant with the FHS:
Well, not really. That FHS section is clear that if you are using /opt, nothing should be installed in (for example) /usr/bin (or even /opt/bin). It also says that configuration files have to go in /etc/opt (ignoring the inconsistent statement in the Rationale section) but the suggestion here is to leave them in /etc. In fact, the suggestion here seems to be more that /opt should be the dumping ground but that links should be used to emulate normal installations (into /usr/bin, /usr/lib, /usr/include, ...). I would not be keen on installing the package into /opt fully in compliance with the FHS as it means files are no longer found in search paths. > So, further to my earlier stance, I don't see a problem with building > a package which is /opt aware for all the above platforms. Now, > maemo-optifying a package and using it on other platforms (and even > Maemo) is a hack, so I'd prefer developers used the autoconf approach > of --datadir or similar, with only a few things (startup script, > icons, service files, desktop files) being either directly installed > to /usr (or symlinked to /opt). For data files it is probably easy to set datadir and have everything work (the path is only used within the package itself although the code may need to be modified to use the macros defined by the configure process). But for executables, libraries and include files it is more of a problem, because they have to be found from outside the package. Will pkg-config handle finding the include files and library files for compilation and linking if they are in a /opt directory? Obviously the .pc file itself would have to be in PKG_CONFIG_PATH but the syntax of a .pc file seems to allow the actual files to be anywhere. Will ld handle finding the library files at run time (i.e. is the path info from the .pc file copied all the way to the executable)? If so, the remaining problem is the executable itself, which will not be in the path. For things only run from a GUI this is not a problem because the .desktop file says where to find it. But for things which are run from the command line they need to be found in the path. I would suggest that Nokia add /opt/bin to the PATH, add /opt/lib to the LD_LIBRARY_PATH and add /opt/lib/pkgconfig to PKG_CONFIG_PATH (all on the device and in scratchbox) and that we ignore the FHS rule that packages should not install into those directories. That would make things a little easier and more robust. We can then build with --prefix=/opt and add a couple of softlinks if necessary for files which still need to be elsewhere. I have no idea whether this will work for python -- how does python find things like libraries (or whatever the equivalent concept is in python)? This proposal will not necessarily allow the package to work on earlier releases because they would not have the PATH's modified. Whether it works or not on an earlier release will be dependent on whether the package is dependent on the paths (in particular, libraries will not work unless they install a symlink to their .pc in /usr/lib/pkgconfig and executables cannot be run from the command line unless they install a symlink into to /usr/bin). Graham _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
