Strano comportamento di apt-get con istruzioni post-inst e file .desktop

Abbiamo un numero di file .deb creati a mano (con fpm e jenkins) in un repository Apt locale (reprepro). Questi .debs contengono un file .desktop che verrà raccolto da xdg-desktop in uno script post-inst.

Se installiamo il file deb manualmente, su un nuovo sistema, tutto va bene.

Se installiamo una nuova versione con apt-get install, otteniamo questo errore

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

Se scarico il file deb con apt-get install -d customthingy ed eseguo

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

Ottengo lo stesso xdg-desktoperrore di prima. Quindi questo esclude un problema con apt.

Se elenco i contenuti del deb scaricato,

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

Puoi vedere che il file esiste.

Tuttavia .. Se eliminiamo prima di reinstallare,

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

E poi

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: contenuto dello 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

Non ci sono errori Quindi .. Le domande sono queste:

1. Questo comportamento previsto o un bug in apt / dpkg?
2. Abbiamo un pacchetto non valido con customthingy.deb che impedisce il funzionamento di una futura reinstallazione?
3. È sicuro supporre che post-inst accadrà sempre alla fine dell'installazione e possiamo tranquillamente presumere che tutti i file saranno stati estratti prima di questo momento?
4. Stiamo facendo qualcosa di enormemente strano?

Immagino che tu postinststia chiamando xdg-desktop-menuper spostare il file desktop in /usr/share/applicationse aggiornare il database desktop XDG. Questo è fatto per esempio google-chrome-stable, ma non riesco a capire perché (continua a leggere)

Se invece installi direttamente il file desktop /usr/share/applications(tramite dpkg - ovvero, inserisci il file lì, dh_installad esempio, in modo tale che il percorso .debsia giusto /usr/share/applications), un certo numero di pacchetti "attiverà" automaticamente gli aggiornamenti: in particolare gnome-menuse desktop-file-utils, ma forse altri (a seconda della versione del sistema operativo di destinazione precisa ecc.)

Almeno nel mio caso, questi sono sufficienti per ottenere ciò che xdg-desktop-menufarebbe l' esecuzione manuale (il programma viene visualizzato immediatamente nei menu utente)

Sono ancora al buio sul perché google-chrome-stablee altri (prevalentemente di terze parti) .debspediscono il file desktop in un posto diverso da /usr/share/applications( /optnel caso di Chrome) e poi lo spostano a mano.

Sono gli script postrm / prerm che chiamano "xdg-desktop-menu --uninstall" il colpevole, ovvero

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

Ciò eliminerà il file .desktop proprio prima che l'invocazione postinst di xdg-desktop-menu tenti di usarlo. Molto bella.

A proposito dei debs google-chrome, includono anche questa strofa nella parte superiore del loro 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

Questo è un approccio pesante per risolvere il problema, ma sembra che stia facendo il trucco qui (e anche per il potente Goog).

Paolo