Fix du lanceur gdebi — Pas de modification du fichier géré par dpkg #53

cf. https://debian-facile.org/viewtopic.php?pid=336795#p336795

Dans le cas de fichiers .desktop au nom identique sous
/usr/share/applications et /usr/local/share/applications, c’est celui
sous /usr/local/share/applications qui sera utilisé.

Mieux vaut ici ne pas modifier le fichier
/usr/share/applications/gdebi.desktop mais plutôt en créer une copie
corrigée /usr/local/share/applications/gdebi.desktop.

Du coup j'ai répondu sur le forum. What say you les autres ?

Histoire de tout avoir dans ce ticket, je copie ici les messages pertinents depuis le forum :

Tout semble bon dans la solution proposée, sauf un point de détail : on n’édite jamais de fichiers sous /usr (sauf ceux sous /usr/local). C’est le territoire réservé des paquets, et y modifier des trucs à la main va provoquer des comportements inattendus à moment ou un autre.

Il y a deux méthodes valable pour corriger ce souci sans modifier /usr/share/applications/gdebi.desktop :

Pour l’utilisateur courant uniquement : copier /usr/share/applications/gdebi.desktop vers ~/.local/share/applications/gdebi.desktop et éditer la copie

Pour tous les utilisateurs du système : copier /usr/share/applications/gdebi.desktop vers /usr/local/share/applications/gdebi.desktop et éditer la copie

par vv222

Hé, c'est pas faux. Et c'est pas la seule occurence à corriger du coup.

Mais y avait un avantage à ce hack "sale" : si la personne supprime le paquet, le .desktop sera supprimé. Alors que s'il est personnalisé, il restera même après suppression du paquet et on aura un "lanceur fantôme qui lance rien" dans les menus. Non ?

Je sais que le compromis que j'avais trouvé c'était de faire un script "post apt" qui vérifie si chaque desktop a un "exec" qui mène a un executable. Mais du coup ça s'éloigne du fonctionnement de debian, et c'était pas le but, du coup j'avais écarté l'idée. ...Et je trouvais ce "mauvais hack" pas si mauvais considérant que debian touche très peu à ces fichiers (et que, même si ça arrivait, ce ne sont pas des fichiers sensibles).

Bonne pratique versus "c'est moche maiiis c'est pratique".

par otyugh

Bien vu, je n’avais pas pris ça en compte.

La solution idéale est bien sûr d’envoyer directement un patch upstream.

par vv222

Je sais même pas si ça vient de l'upstream. Tu sais s'il existe chez Ubuntu ce problème ?

par otyugh

Histoire de tout avoir dans ce ticket, je copie ici les messages pertinents depuis le forum : > Tout semble bon dans la solution proposée, sauf un point de détail : on n’édite **jamais** de fichiers sous `/usr` (sauf ceux sous `/usr/local`). C’est le territoire réservé des paquets, et y modifier des trucs à la main va provoquer des comportements inattendus à moment ou un autre. > > Il y a deux méthodes valable pour corriger ce souci sans modifier `/usr/share/applications/gdebi.desktop` : > > * Pour l’utilisateur courant uniquement : copier `/usr/share/applications/gdebi.desktop` vers `~/.local/share/applications/gdebi.desktop` et éditer la copie > * Pour tous les utilisateurs du système : copier `/usr/share/applications/gdebi.desktop` vers `/usr/local/share/applications/gdebi.desktop` et éditer la copie [par vv222](https://debian-facile.org/viewtopic.php?pid=336795#p336795) > Hé, c'est pas faux. Et c'est pas la seule occurence à corriger du coup. > > Mais y avait un avantage à ce hack "sale" : si la personne supprime le paquet, le .desktop sera supprimé. Alors que s'il est personnalisé, il restera même après suppression du paquet et on aura un "lanceur fantôme qui lance rien" dans les menus. Non ? > > Je sais que le compromis que j'avais trouvé c'était de faire un script "post apt" qui vérifie si chaque desktop a un "exec" qui mène a un executable. Mais du coup ça s'éloigne du fonctionnement de debian, et c'était pas le but, du coup j'avais écarté l'idée. ...Et je trouvais ce "mauvais hack" pas si mauvais considérant que debian touche très peu à ces fichiers (et que, même si ça arrivait, ce ne sont pas des fichiers sensibles). > > Bonne pratique versus "c'est moche maiiis c'est pratique". [par otyugh](https://debian-facile.org/viewtopic.php?pid=336811#p336811) > Bien vu, je n’avais pas pris ça en compte. > > La solution idéale est bien sûr d’envoyer directement un patch [upstream](https://code.launchpad.net/~gdebi-developers/gdebi/trunk). [par vv222](https://debian-facile.org/viewtopic.php?pid=336830#p336830) > Je sais même pas si ça vient de l'upstream. Tu sais s'il existe chez Ubuntu ce problème ? [par otyugh](https://debian-facile.org/viewtopic.php?pid=336831#p336831)

coucou :)

si vous avez testé, pourquoi personne n'a fusionné cette demande ? un truc particulier à tester en plus ? sinon, bah go pour la fusion :D

Parce qu'il y a un prix à payer !

Mais y avait un avantage à ce hack “sale” (qu'on utilise actuellement) : si la personne supprime le paquet, le .desktop sera supprimé. Alors que s’il est personnalisé (comme le ferait cette branche), il restera même après suppression du paquet et l'utilisateur se retrouve avec un “lanceur fantôme qui lance rien” dans les menus. Et ça demande un peu de connaissance pour le virer manuellement.

Personnellement je trouve plus user friendly de laisser tel quel, c'est pour ça que je n'ai pas fusionné. Mais ce n'est que mon avis qui n'est pas décisif de tout ! C'est la faute aux autre de pas avoir d'avis :p

ah oki, bien vu... mais je vois mal nos débutants supprimer gdebi en fait.
donc je serais pour fusionner et si jamais un user en vient à supprimer gdebi, il aura un lanceur vide mais nous pourrons lui indiquer facilement comment le virer.

ça me semble la meilleure solution pour éviter le bug tout en conservant le contrôle sur le possible second bug en cas de suppression de gdebi

ça me semble la meilleure solution pour éviter le bug

Le bug est déjà évité, c'est juste un différent workaround :o

En tous cas si on commence par là, y a tous les ".desktop" que j'ai touché de la même manière (une grosse quinzaine https://debian-facile.org/git/ProjetsDF/dfiso-buster/src/branch/master/config/includes.chroot/usr/share/applications) (une partie n'était pas traduite ou dans les lignes étaient dans un ordre tel que whiskermenu perdait ses petits - problème réglé tout seul dès bullseye). Du coup tous ceux-là seraient aussi à faire passer dans /etc/skel (ou à supprimer si on considère que ça vaut pas le coup).

Mais du coup ça fait beaucoup d'entrées .desktop fantôme potentielles. Amh :(

oui, j'ai vu tes patch-desktop ...

c'est un autre soucis les manques de traduction : si le user supprime ou si le paquet est mis à jour, le .desktop sera modifié, et c'est pas grave, juste pour une histoire de trad, en revanche, le hack de gdebi est obligatoire pour que gdebi puisse fonctionner.

donc si gdebi est mis à jour et son .desktop écrasé, il ne fonctionnera plus, d'ou l'obligation de le coller dans /local
pour les autres, l'écrasement des .desktop n'empêchera pas l'excécution des aplications :)

Une possibilité, c'est de créer un .deb qui installe le .desktop dans /u/local/s/ et qui dépende de gdebi. Comme ça, si l'utilisateur vire gdebi, la dépendence sautera avec.

un fake-deb pour pallier aux bugs de Debian .... j'adore l'idée :D :D

je m'occupe de ça dans la journée ;)

et hop .. on peut fermer ici, j'ai push 9d8e0f890f

merci @captnfab :)

Top @arpinux !