Home / server / Questions / 346457
Accepted
Tom O'Connor
Asked: 2012-01-05 03:15:17 +0800 CST

Odd behavior of apt-get with post-inst instructions, and .desktop files

  • 772

We have a number of hand-built (with fpm and jenkins) .deb files in a local Apt repository (reprepro). These .debs contain a .desktop file that will be picked up by xdg-desktop in a post-inst script.

If we install the deb file by hand, on a new system, everything is fine.

If we install a new version with apt-get install, we get this error

xdg-desktop-menu: file '/usr/local/share/applications/customthingy.desktop' does not exist

If I download the deb file with apt-get install -d customthingy, and run 

dpkg -i /var/cache/apt/archives/customthingy_2-r3_all.deb

I get the same, xdg-desktop error as before. So that rules out a problem with apt.

If I list the contents of the downloaded deb,

tom.oconnor@charcoal-black:~$ dpkg --contents /var/cache/apt/archives/customthingy_2-r3_all.deb |grep ".desktop"
-rw-r--r-- root/root       201 2011-07-28 20:02 ./usr/local/share/applications/customthingy.desktop

You can see the file exists.

However.. If we purge before reinstalling, 

tom.oconnor@charcoal-black:~$ sudo apt-get purge customthingy
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED
  customthingy*
0 upgraded, 0 newly installed, 1 to remove and 84 not upgraded.
After this operation, 0B of additional disk space will be used.
Do you want to continue [Y/n]? y
(Reading database ... 219342 files and directories currently installed.)
Removing customthingy ...
Purging configuration files for customthingy ...

And then

tom.oconnor@charcoal-black:~$ sudo apt-get install customthingy
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed
  customthingy
0 upgraded, 1 newly installed, 0 to remove and 84 not upgraded.
Need to get 0B/4,030B of archives.
After this operation, 0B of additional disk space will be used.
Selecting previously deselected package customthingy.
(Reading database ... 219319 files and directories currently installed.)
Unpacking customthingy (from .../customthingy_2-r3_all.deb) ...
Setting up customthingy (2-r3) ...

EDIT: Contents of Postinst script

#!/bin/sh

# Add an entry to the system menu

XDG_DESKTOP_MENU="`which xdg-desktop-menu 2> /dev/null`"

if [ ! -x "$XDG_DESKTOP_MENU" ]; then
  echo "WARNING: Could not find xdg-desktop-menu" >&2
else
  "$XDG_DESKTOP_MENU" install --mode system /usr/local/share/applications/customthingy.desktop
  "$XDG_DESKTOP_MENU" forceupdate --mode system
fi

There's no error. So.. The questions are these:

  1. Is this expected behavior, or a bug in apt/dpkg?
  2. Do we have a malformed package with customthingy.deb that is preventing a future reinstall run from working?
  3. Is it safe to assume that post-inst will always happen at the very end of installation, and we can safely assume that all files will have been extracted before this point in time?
  4. Are we doing something massively weird?
apt package-management dpkg

2 Answers

  1. Best Answer

    I'm guessing your postinst is calling xdg-desktop-menu to move the desktop file into /usr/share/applications and update the XDG desktop database. This is done by e.g. google-chrome-stable, but I cannot fathom why (read on)

    If you install the desktop file directly into /usr/share/applications instead (via dpkg — that is, put the file there via dh_install for example, such that the path in the .deb is just /usr/share/applications), a number of packages will automatically 'trigger' updates: notably gnome-menus and desktop-file-utils, but perhaps others (depending on the precise target OS version etc.)

    At least in my case, these are sufficient to achieve what running xdg-desktop-menu by hand would do (the program shows up in my user menus immediately)

    I'm still in the dark as to why google-chrome-stable and other (predominantly 3rd party) .debs ship the desktop file into somewhere other than /usr/share/applications (/opt in chrome's case) and then move it by-hand.

    • 5

  2. It's the postrm/prerm scripts calling "xdg-desktop-menu --uninstall' that are the culprit, i.e.

    "$XDG_DESKTOP_MENU" uninstall --mode system /usr/local/share/applications/customthingy.desktop

    That will delete the .desktop file right before the postinst invocation of xdg-desktop-menu tries to use it. Very nice.

    Speaking of the google-chrome debs, they also include this stanza at the top of their prerm script:

    action="$1"
if [ "$2" = "in-favour" ]; then
  # Treat conflict remove as an upgrade.
  action="upgrade"
fi
# Don't clean-up just for an upgrade.`
if [ "$action" = "upgrade" ] ; then
  exit 0
fi

    This is a heavy-handed approach to fixing the problem but seems to be doing the trick over here (and for the mighty Goog too).

    Paul

    • 2