[erledigt] Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
JTH
Moderator
Beiträge: 1053
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von JTH » 29.03.2021 19:52:47

LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:09:23
Ich habe die genannten *.desktop-Dateien jedenfalls nach /usr/local/share/applications/*.desktop.orig verschoben
Den Schritt kannst du dir wahrscheinlich sparen. Wenn in /usr/share/applications eine .desktop mit exakt demselben Namen wie eine in /usr/local/share/applications existiert, sollte die erstere ignoriert und nur die letztere verwendet werden:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#desktop-file-id hat geschrieben: If multiple files have the same desktop file ID [=filename], the first one in the $XDG_DATA_DIRS precedence order is used.
Der Standardwert von XDG_DATA_DIRS gibt obiges her, nämlich dass Dateien in /usr/local/share jenen in /usr/share vorgezogen werden:

Code: Alles auswählen

~$ echo $XDG_DATA_DIRS
/usr/share/gnome:/usr/local/share/:/usr/share/

LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:09:23
Und dafür gibt es auch eine eigene /usr/local/share/applications/intranetbrowser.desktop
Benenn die doch mal in firefox-esr.desktop um und guck, ob alles wie gehabt, gewollt und oben beschrieben weiter funktioniert. Und spar dir dann die extra Arbeit in /usr/share/applications bei Updates.

Nebenbei: Wäre zum Ändern der Startseite nicht eine Konfig für den FF in /etc sinnvoller? (Ich meine, da gibt es Wege.)
Zuletzt geändert von JTH am 29.03.2021 20:30:36, insgesamt 1-mal geändert.

Benutzeravatar
hikaru
Moderator
Beiträge: 11517
Registriert: 09.04.2008 12:48:59

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von hikaru » 29.03.2021 20:19:30

cronoik hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 15:59:49
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 13:41:26
Ich würde ja sagen, dass jemand der Thunderbird an der Debian-Paketverwaltung vorbei installiert dafür gute Gründe hat, denen er sich auch bewust ist. Und dieser jemand möchte dann auch sicher seine "mühevoll" installierte Spezialversion standardmäßig starten und nicht das, was ihm Debian vorsetzt. Andernfalls hätte er sich die Mühe wohl nicht gemacht.
So jemand duerfte aber auch mit dem geschilderten "Problem" umgehen koennen.
Ja, dürfte er. Die Frage ist, welches Verhalten so jemand bevorzugen würde.

LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:09:23
Wer ist in Deinem Fall dieser jemand?
Du vielleicht? Du hast nicht genau verraten was du vor hast, aber prinzipiell würde jeder der die Standardkonfiguration des Systems verändern möchte, das gern mit möglichst geringem Aufwand tun.
LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:09:23
Der Nutzer kann in seinem $HOME das ja machen. - Wo ist das Problem?
Möglicherweise steht das System nicht unter Kontrolle des Nutzers und /home ist mit noexec gemountet. Dann ist er auf die Kooperation von root angewiesen um sein Programm zu bekommen. Das dürften typischerweie echte Mehrbenutzersysteme sein und root auf solchen Systemen möchte tendenziell möglichst wenig wegen spezieler Nutzerwünsche am System rumschrauben.

cronoik
Beiträge: 2037
Registriert: 18.03.2012 21:13:42
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von cronoik » 29.03.2021 20:43:28

LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:09:23
Aber genau darum geht es doch. Der Admin "ordnet" über /usr/local/bin etwas an und das Grundsystem behindert den Admin, indem absolute Pfade in /usr/share/applications/*.desktop verwendet werden. Ein anderer als der Admin kann in /usr/local/bin sowieso nichts "anordnen".
Ich sehe darin keine Behinderung. Paket A wird installiert und bringt eine .desktop Datei mit. Jetzt installiere ich eine andere Version dieser Software (sagen wir B) und ich empfaende es als voellig falsch wenn die .desktop Datei aus A nun zum Starten von B genutzt werden kann. Denn das heisst naemlich auch, dass wenn ich A deinstalliere, verschwindet der Starter von B.

Ich wuerde deiner Ansicht zustimmen wenn es ein Paket gebe das alle .desktop Dateien ausliefert, aber da die .desktop Dateien im jeweilen Paket sind ist meine Erwartungshaltung das auch nur die Sachen aus dem Paket genutzt werden.
LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:09:23
Genau das habe ich auf meinem System in /usr/local/bin habe ich ein zusätzliches Script intranetbrowser das /usr/bin/firefox-esr mit einer anderen Berechtigung aufruft und eine andere Startseite, nämlich Links auf Intranet, lädt. Und dafür gibt es auch eine eigene /usr/local/share/applications/intranetbrowser.desktop
Das ist aber ein anderes Szenario. Ich hatte eher im Sinn das ich Firefox 2.X fuer etwas benoetige und ausrolle. Es waere doch fatal wenn jetzt jeder Nutzer ueber seinen firefox starter diese Version starten wuerde weil dort relative Pfade verwendet werden wuerden (wir gehen jetzt mal von Namensgleichheit der Dateien aus). Natuerlich ist es meine Aufgabe als Admin mich darum zukuemmern, ich sehe hier relative Pfade aber eher als Fallstrick.
curt123 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:52:23
Ich habe recht unterschiedliche Empfehlungen gefunden, wo selbstgeschriebene Skripte, zumal wenn sie im Pfad liegen sollen, hingehören. Momentan landen die hier meistens in /usr/local/bin, auch wenn es bei Änderungen umständlicher ist. So ist es wohl i.d.R. besser, als ein Verzeichnis unter /home/user in den Pfad zu nehmen, oder gibt es da bessere Möglichkeiten / Konventionen?
/usr/local/bin ist da schon der richtige Weg. [1] Falls es sich aber um ein Einbenutzersystem handelt, dann spricht doch auch nichts um eine einmalige PATH Erweiterung ueber die ~/.profile.

[1] https://www.pathname.com/fhs/pub/fhs-2. ... OCALSHARE1
Hilf mit unser Wiki zu verbessern!

Benutzeravatar
hikaru
Moderator
Beiträge: 11517
Registriert: 09.04.2008 12:48:59

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von hikaru » 29.03.2021 21:13:23

cronoik hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 20:43:28
Paket A wird installiert und bringt eine .desktop Datei mit. Jetzt installiere ich eine andere Version dieser Software (sagen wir B) und ich empfaende es als voellig falsch wenn die .desktop Datei aus A nun zum Starten von B genutzt werden kann. Denn das heisst naemlich auch, dass wenn ich A deinstalliere, verschwindet der Starter von B.
Das ist ein guter Punkt!
Die .desktop-Datei wird von einem Paket ausgeliefert. Eine Fremdsoftware mit GUI sollte saubererweise eine eigene .desktop-Datei mitbringen. Wenn die aber beide an gleicher Stelle landen, dann gibt es einen Zuständigkeitskonflikt.
Würde man das mit Debian-Paketen probieren, indem man z.B. ein unsauberes Fremdrepo einbindet, das in einem anderen Paket (ohne Conflicts:) die gleichen Dateien aiusliefert, dann meckert apt, weil es nicht die gleiche Datei aus zwei Paketen akzeptiert.
Man könnte das sauber lösen, indem das Fremdpaket z.B. alles nach /usr/local instaliert, inklusive seiner .desktop-Datei. Dann ist es auch wieder egal ob in der Datei unter /usr/share/applications ein Pfad steht.

Unschön finde ich es trotzdem, dass offizielle Debian-Pakete .desktop-Dateien mit Pfaden für Binaries auslieferrn.

LinuxFanKR13
Beiträge: 64
Registriert: 19.04.2020 10:01:02

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von LinuxFanKR13 » 29.03.2021 22:27:47

Hallo zusammen,
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 21:13:23
Das ist ein guter Punkt!
Die .desktop-Datei wird von einem Paket ausgeliefert. Eine Fremdsoftware mit GUI sollte saubererweise eine eigene .desktop-Datei mitbringen. Wenn die aber beide an gleicher Stelle landen, dann gibt es einen Zuständigkeitskonflikt.
Dagegen ist doch auch gar nichts einzuwenden. Ein Paket der Distribution installiert seine ausführbare Datei nach /usr/bin und seine .desktop-Datei nach /usr/share/applications. Durch Vermeidung von absoluten Pfaden in der *.desktop-Datei ermöglicht das Paket dem Admin das Ergänzen von Pre- und Post-Conditions über gleichnamige Scripte in /usr/local/bin. Nicht mehr und nicht weniger. Es geht ja gar nicht darum, ein anderes Paket zu installieren, sondern nur darum, das Programm aus der Distribution "lokal-angepasst" zu nutzen. Wenn die *.desktop-Datei absolute Pfade enthält, muss der Admin zusätzlich eine *.desktop-Datei erzeugen, was eigentlich unnötig ist. Und das habe ich als "Behinderung" des Admins beschrieben.

Ein ganz anderes Paket bringt seine eigene ausführbare Datei (mit anderem Namen) und eigener .desktop-Datei mit.
Wo soll es da einen Zugriffskonflikt geben, wenn jedes Paket/Programm seinen eindeutigen Namen hat?

Ich werde mal testen, ob ich die *.desktop-Datei mit absoluten Pfaden in /usr/share/applications belassen kann und nur die /usr/local/share/applications/*.desktop brauche. Dann ist der Aufwand für *.desktop-Dateien mit absoluten Pfaden "nur" ein einmaliger, aus meiner Sicht dennoch unnötiger Aufwand.

Wenn /home mit noexec gemountet ist, dann stellt der Admin ein - hoffentlich vorher an alle Beteiligten kommuniziertes - System zur Verfügung, das den Nutzern nicht erlaubt, ausführbare Dateien in ihrem $HOME zu haben. Dies ist dann eine andere Policy und hat mit dem beschriebenen Thema nichts zu tun.

Meine /usr/local/share/applications/intranetbrowser.desktop ruft firefox-esr mit dem "normalen" User auf und ist so eingestellt, dass es nur auf das Intranet zugreift und nicht nach draußen geht. Es könnte auch ein "alter Browser" sein, der aus Kompatibilitätsgründen noch benötigt wird.
/usr/local/bin/firefox-esr ruft hingegen /usr/bin/firefox-esr unter einem anderen User auf, so dass das Programm nicht an die Daten des Users heran kommt.

Viele Grüße

LinuxFanKR13
Beiträge: 64
Registriert: 19.04.2020 10:01:02

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von LinuxFanKR13 » 31.03.2021 12:37:27

Hallo Community,

ich habe geprüft, dass es in der Tat genügt, zusätzlich zu den /usr/share/applications*.desktop-Dateien mit absoluten Pfadangaben unter /usr/local/share/applications/*.desktop gleichnamige Dateien ohne absolute Pfadangaben bereit zu stellen. Dann werden diese in die Menüs übernommen und per /usr/local/bin/script kann man den Programmnamen "überladen".

Fazit:
Absolute Pfade in *.desktop-Dateien sind für mich nach wie vor nicht sinnvoll, aber der Aufwand für die Korrektur ist eine einmalige Aktion, wenn ein neues Paket installiert wird, nicht aber wenn ein bereits vorhandenes Paket ein Update erfährt, das nichts Grundlegendes ändert.

Vielen Dank für die Unterstützung und viele Grüße

Antworten