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

Closed
vv222 wants to merge 1 commits from fix-gdebi-desktop-hack into master
vv222 commented 1 year ago

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.

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`.
otyugh commented 1 year ago
Collaborator

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

Du coup j'ai répondu sur le forum. What say you les autres ?
vv222 commented 1 year ago
Owner

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)
arpinux commented 11 months ago
Collaborator

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

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
otyugh commented 11 months ago
Collaborator

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

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
arpinux commented 11 months ago
Collaborator

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

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
otyugh commented 11 months ago
Collaborator

ç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 :(

> ç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 :(
arpinux commented 11 months ago
Collaborator

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

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 :)
captnfab commented 11 months ago
Owner

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.

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.
arpinux commented 11 months ago
Collaborator

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

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 ;)
arpinux commented 11 months ago
Collaborator

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

merci @captnfab :)

et hop .. on peut fermer ici, j'ai push https://debian-facile.org/git/ProjetsDF/dfiso-buster/commit/9d8e0f890f30c15771e023331afe70bc0f853671 merci @captnfab :)
arpinux closed this pull request 11 months ago
sushy commented 11 months ago

Top @arpinux !

Top @arpinux !
This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.