Seltsames Verhalten von apt-get mit Post-Inst-Anweisungen und .desktop-Dateien

Wir haben eine Reihe von handgefertigten (mit fpm und jenkins) .deb-Dateien in einem lokalen Apt-Repository (reprepro). Diese .debs enthalten eine .desktop-Datei, die von xdg-desktop in einem Post-Inst-Skript abgerufen wird.

Wenn wir die Deb-Datei von Hand auf einem neuen System installieren, ist alles in Ordnung.

Wenn wir eine neue Version mit apt-get install installieren, wird dieser Fehler angezeigt

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

Wenn ich die Deb-Datei mit apt-get install -d customthingy herunterlade und ausführe

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

Ich bekomme den gleichen xdg-desktopFehler wie zuvor. Das schließt also ein Problem mit apt aus.

Wenn ich den Inhalt der heruntergeladenen Debatte aufführe,

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

Sie können sehen, dass die Datei vorhanden ist.

Wenn wir jedoch vor der Neuinstallation bereinigen,

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

Und dann

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

BEARBEITEN: Inhalt des Postinst-Skripts

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

Es gibt keinen Fehler. Also .. Die Fragen sind folgende:

1. Ist das erwartetes Verhalten oder ein Fehler in apt / dpkg?
2. Haben wir ein fehlerhaftes Paket mit customthingy.deb, das verhindert, dass ein zukünftiger Neuinstallationslauf funktioniert?
3. Ist es sicher anzunehmen, dass Post-Inst immer am Ende der Installation stattfindet, und wir können davon ausgehen, dass alle Dateien vor diesem Zeitpunkt extrahiert wurden?
4. Tun wir etwas massiv Seltsames?

Ich vermute, Sie postinstrufen xdg-desktop-menuan, um die Desktop-Datei in /usr/share/applicationsdie XDG-Desktop-Datenbank zu verschieben und diese zu aktualisieren. Dies geschieht zB von google-chrome-stable, aber ich kann nicht verstehen warum (weiterlesen)

Wenn Sie die Desktop-Datei /usr/share/applicationsstattdessen direkt in installieren (über dpkg - das heißt, legen Sie die Datei dh_installbeispielsweise über dort ab, sodass der Pfad in der .debgerade ist /usr/share/applications), lösen eine Reihe von Paketen automatisch Updates aus: insbesondere gnome-menusund desktop-file-utils, aber vielleicht andere (abhängig von der genauen Zielversion des Betriebssystems usw.)

Zumindest in meinem Fall reichen diese aus, um das zu erreichen, was das Ausführen xdg-desktop-menuvon Hand bewirken würde (das Programm wird sofort in meinen Benutzermenüs angezeigt).

Ich bin immer noch im Dunkeln darüber, warum google-chrome-stableund andere (überwiegend von Drittanbietern) .debdie Desktop-Datei an einen anderen Ort als /usr/share/applications( /optim Fall von Chrome) versenden und sie dann von Hand verschieben.

Es sind die postrm / prerm-Skripte, die "xdg-desktop-menu --uninstall" aufrufen, die den Schuldigen sind, dh

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

Dadurch wird die .desktop-Datei gelöscht, bevor der Postinst-Aufruf von xdg-desktop-menu versucht, sie zu verwenden. Sehr schön.

Apropos Google-Chrome-Debs: Diese Strophe steht auch ganz oben in ihrem Prerm-Skript:

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

Dies ist ein hartnäckiger Ansatz zur Behebung des Problems, scheint aber hier (und auch für den mächtigen Goog) den Trick zu tun.

Paul