Comportement étrange d'apt-get avec des instructions post-inst et des fichiers .desktop

Nous avons un certain nombre de fichiers .deb construits à la main (avec fpm et jenkins) dans un référentiel Apt local (reprepro). Ces .debs contiennent un fichier .desktop qui sera récupéré par xdg-desktop dans un script post-inst.

Si nous installons le fichier deb à la main, sur un nouveau système, tout va bien.

Si nous installons une nouvelle version avec apt-get install, nous obtenons cette erreur

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

Si je télécharge le fichier deb avec apt-get install -d customthingy et exécute

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

J'obtiens le même, xdg-desktoperreur comme avant. Donc, cela exclut un problème avec apt.

Si j'énumère le contenu du deb téléchargé,

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

Vous pouvez voir que le fichier existe.

Cependant .. Si nous purgeons avant de réinstaller,

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 ...

Et alors

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: Contenu du script Postinst

#!/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

Il n'y a pas d'erreur. Alors .. Les questions sont les suivantes:

1. S'agit-il d'un comportement attendu ou d'un bogue dans apt / dpkg?
2. Avons-nous un paquet mal formé avec customthingy.deb qui empêche une future réinstallation de fonctionner?
3. Est-il sûr de supposer que post-inst se produira toujours à la toute fin de l'installation, et nous pouvons supposer que tous les fichiers auront été extraits avant ce moment?
4. Faisons-nous quelque chose de très bizarre?

Je suppose que vous postinstappelez xdg-desktop-menupour déplacer le fichier de bureau dans /usr/share/applicationset mettre à jour la base de données de bureau XDG. Cela se fait par exemple google-chrome-stable, mais je ne peux pas comprendre pourquoi (lire la suite)

Si vous installez le fichier de bureau directement à la /usr/share/applicationsplace (via dpkg - c'est-à-dire, placez-le via dh_installpar exemple, de telle sorte que le chemin dans le .debsoit juste /usr/share/applications), un certain nombre de packages déclenchera automatiquement des mises à jour: notamment gnome-menuset desktop-file-utils, mais peut-être autres (en fonction de la version précise du système d'exploitation cible, etc.)

Au moins dans mon cas, ceux-ci sont suffisants pour réaliser ce que faire xdg-desktop-menuà la main ferait (le programme apparaît immédiatement dans mes menus utilisateur)

Je suis toujours dans l'obscurité pour expliquer pourquoi google-chrome-stableet d' autres (principalement 3ème partie) .debs expédier le fichier de bureau dans un endroit autre que /usr/share/applications( /optdans le cas de chrome) et de passer ensuite par la main.

Ce sont les scripts postrm / prerm appelant "xdg-desktop-menu --uninstall" qui sont le coupable, c'est-à-dire

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

Cela supprimera le fichier .desktop juste avant que l'invocation postinst de xdg-desktop-menu ne tente de l'utiliser. Très agréable.

En parlant des debuts google-chrome, ils incluent également cette strophe en haut de leur script prerm:

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

Il s'agit d'une approche lourde pour résoudre le problème, mais semble faire l'affaire ici (et pour le puissant Goog aussi).

Paul