[CMake] Fwd: How to package for Debian with Qt dependencies

[Carlo Nicolini]

On Tue, Apr 10, 2012 at 03:01:20PM +0200, Carlo Nicolini wrote:
> You say that it's impossible only by using cmake/cpack to create a debian
> package that automatically installs all the needed dependencies?
> I thought it was possible.

Well, of course that's likely possible (via BundleUtilities fixup_bundle()
etc., which packages all custom dependencies), but it's not desired in most
cases. For standard dependencies which are already offered by the system's
package management, it is a _bad_ idea to custom-include them within
the package.

> And what about the way to make a link to the program inside the
Application
> toolbar (in Ubuntu for example)? or making the installed program available
> via command line without the need to moving it into /usr/bin?
>
> I found no way til now...

For menu installation tasks, it's strongly recommended to make use of
freedesktop.org xdg-utils scripts
(which, ironically, are STRONGLY RECOMMENDED to be included within the
package, in a sufficiently [very!] modern form),
which offer proper generic installation for all sorts of Linux distros.

My [app]_menu.sh (taking "install"/"uninstall" parms) looks like:

#!/bin/sh
#
# NOTE: at least on certain Ubuntu versions, desktop menu handling is
# __BUGGY__ (you need to log out to get registrations updated!).
Unbelievable.
# See " "xdg-desktop-menu install" requires a logout the first time",
# https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/191958

CMD=$1

if [ "$CMD" != "install" -a "$CMD" != "uninstall" ]; then
 echo "Need to specify either install or uninstall argument, exiting!"
 exit 1
fi

echo -n "$CMD""ing [APP] menu entries..."

SCRIPTDIR="$(cd "$(dirname "$0")" 2>/dev/null && pwd)"

cd "${SCRIPTDIR}"

export PATH="$PATH:$SCRIPTDIR" # strongly recommended by FDO (choose
system-specific xdg tools first)

# NOTE: restrictive permissions may easily cause unprocessed menu entries
# for non-root users! (without any warning emitted by the xdg tools!!!)
# Thus better make sure we always provide proper permissions!
chmod 644 [vendor]-[app]_menu_16.png [vendor]-[app]_menu_32.png
[vendor]-[app].desktop

# use --noupdate, for efficient global generation via forceupdate later
xdg-icon-resource $CMD --noupdate --size 16 [vendor]-[app]_menu_16.png
[vendor]-[app]
xdg-icon-resource $CMD --noupdate --size 32 [vendor]-[app]_menu_32.png
[vendor]-[app]
xdg-icon-resource forceupdate
xdg-desktop-menu $CMD [vendor]-[app].desktop

echo " done."
echo




You need to invoke this script within the Debian postinst.in that will be
installed within the package.
For comfortable viewing of (RPM, .deb) package contents,
definitely make use of mc (Midnight Commander).




For the install location topic, things should be viewed in this light:

on UNIX you've got a (customizable!!) installation PREFIX
(/usr, /opt, /usr/local or some such), and people can
(and ideally should be able to) specify any PREFIX that they want
to install to (terminus technicus: relocatable RPM, rpm --relocate etc.).
Or just think of shar archives (see sharutils,
or similar CPack STGZ archive generator)
which also are supposed to be extractable to anywhere
(e.g. user home directory or so).

Thus, your package could have files install()ed as
bin/application_launcher
lib/app-[VERSION]/bin
lib/app-[VERSION]/lib
lib/app-[VERSION]/plugins

and then bin/application_launcher could be a simple
shell-based forwarder script (or perhaps just a symlink, but symlinks
in packages/installers are *VERY* problematic):
#!/bin/sh
@RELATIVE_PATH_TO_APP@/application "${@}"

(this template properly configure_file()d and install()ed in CMake code,
and RELATIVE_PATH_TO_APP needs to be figured out via file(RELATIVE_PATH
...)).

Also, when packaging for several CPack generators, you definitely
want to eventually progress towards making use of a nicely customized
set(CPACK_PROJECT_CONFIG_FILE "CPackOptions.cmake")
, to tweak certain CPack generator settings (and configure_file()
certain files from their templates) at __per-generator install time__
(rather than CMake configure time).

HTH,

Andreas Mohr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120410/0a82e437/attachment.htm>