<br><div class="gmail_quote"><div class="im">
On Tue, Apr 10, 2012 at 03:01:20PM +0200, Carlo Nicolini wrote:<br>
> You say that it's impossible only by using cmake/cpack to create a debian<br>
> package that automatically installs all the needed dependencies?<br>
> I thought it was possible.<br>
<br>
</div>Well, of course that's likely possible (via BundleUtilities fixup_bundle()<br>
etc., which packages all custom dependencies), but it's not desired in most<br>
cases. For standard dependencies which are already offered by the system's<br>
package management, it is a _bad_ idea to custom-include them within<br>
the package.<br>
<div class="im"><br>
> And what about the way to make a link to the program inside the Application<br>
> toolbar (in Ubuntu for example)? or making the installed program available<br>
> via command line without the need to moving it into /usr/bin?<br>
><br>
> I found no way til now...<br>
<br>
</div>For menu installation tasks, it's strongly recommended to make use of<br>
<a href="http://freedesktop.org" target="_blank">freedesktop.org</a> xdg-utils scripts<br>
(which, ironically, are STRONGLY RECOMMENDED to be included within the<br>
package, in a sufficiently [very!] modern form),<br>
which offer proper generic installation for all sorts of Linux distros.<br>
<br>
My [app]_menu.sh (taking "install"/"uninstall" parms) looks like:<br>
<br>
#!/bin/sh<br>
#<br>
# NOTE: at least on certain Ubuntu versions, desktop menu handling is<br>
# __BUGGY__ (you need to log out to get registrations updated!). Unbelievable.<br>
# See " "xdg-desktop-menu install" requires a logout the first time",<br>
# <a href="https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/191958" target="_blank">https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/191958</a><br>
<br>
CMD=$1<br>
<br>
if [ "$CMD" != "install" -a "$CMD" != "uninstall" ]; then<br>
echo "Need to specify either install or uninstall argument, exiting!"<br>
exit 1<br>
fi<br>
<br>
echo -n "$CMD""ing [APP] menu entries..."<br>
<br>
SCRIPTDIR="$(cd "$(dirname "$0")" 2>/dev/null && pwd)"<br>
<br>
cd "${SCRIPTDIR}"<br>
<br>
export PATH="$PATH:$SCRIPTDIR" # strongly recommended by FDO (choose system-specific xdg tools first)<br>
<br>
# NOTE: restrictive permissions may easily cause unprocessed menu entries<br>
# for non-root users! (without any warning emitted by the xdg tools!!!)<br>
# Thus better make sure we always provide proper permissions!<br>
chmod 644 [vendor]-[app]_menu_16.png [vendor]-[app]_menu_32.png [vendor]-[app].desktop<br>
<br>
# use --noupdate, for efficient global generation via forceupdate later<br>
xdg-icon-resource $CMD --noupdate --size 16 [vendor]-[app]_menu_16.png [vendor]-[app]<br>
xdg-icon-resource $CMD --noupdate --size 32 [vendor]-[app]_menu_32.png [vendor]-[app]<br>
xdg-icon-resource forceupdate<br>
xdg-desktop-menu $CMD [vendor]-[app].desktop<br>
<br>
echo " done."<br>
echo<br>
<br>
<br>
<br>
<br>
You need to invoke this script within the Debian <a href="http://postinst.in" target="_blank">postinst.in</a> that will be installed within the package.<br>
For comfortable viewing of (RPM, .deb) package contents,<br>
definitely make use of mc (Midnight Commander).<br>
<br>
<br>
<br>
<br>
For the install location topic, things should be viewed in this light:<br>
<br>
on UNIX you've got a (customizable!!) installation PREFIX<br>
(/usr, /opt, /usr/local or some such), and people can<br>
(and ideally should be able to) specify any PREFIX that they want<br>
to install to (terminus technicus: relocatable RPM, rpm --relocate etc.).<br>
Or just think of shar archives (see sharutils,<br>
or similar CPack STGZ archive generator)<br>
which also are supposed to be extractable to anywhere<br>
(e.g. user home directory or so).<br>
<br>
Thus, your package could have files install()ed as<br>
bin/application_launcher<br>
lib/app-[VERSION]/bin<br>
lib/app-[VERSION]/lib<br>
lib/app-[VERSION]/plugins<br>
<br>
and then bin/application_launcher could be a simple<br>
shell-based forwarder script (or perhaps just a symlink, but symlinks<br>
in packages/installers are *VERY* problematic):<br>
#!/bin/sh<br>
@RELATIVE_PATH_TO_APP@/application "${@}"<br>
<br>
(this template properly configure_file()d and install()ed in CMake code,<br>
and RELATIVE_PATH_TO_APP needs to be figured out via file(RELATIVE_PATH ...)).<br>
<br>
Also, when packaging for several CPack generators, you definitely<br>
want to eventually progress towards making use of a nicely customized<br>
set(CPACK_PROJECT_CONFIG_FILE "CPackOptions.cmake")<br>
, to tweak certain CPack generator settings (and configure_file()<br>
certain files from their templates) at __per-generator install time__<br>
(rather than CMake configure time).<br>
<br>
HTH,<br>
<br>
Andreas Mohr<br>
</div><br>