yaourt 0.9.2.4-1 boucle sur l'édition du PKGBUILD

[Le_J]

Bonjour,

Je viens de mettre à jour yaourt à la version 0.9.2.4-1 et maintenant, lorsque je met à jour ou installe un nouveau paquet à partir de AUR, yaourt boucle sur l'édition du PKGBUILD tant que l'on ne tape pas "n".

Est-ce un bug, une nouvelle fonctionalité ou une erreur de ma part ?

Si celà peut jouer, j'ai un archlinux 64bits.

[tuxce]

wain confirmera ou infirmera, mais d'après ce que je vois dans le code, il apparaît que oui.
Si tu décides d'éditer le PKGBUILD, yaourt parse ce dernier pour trouver les différentes dépendances, te les affiche et te re-propose l'édition au cas où.

Ce qui est pas plus mal d'ailleurs

par contre, @wain, tu pourrais utiliser par exemple:

Code : Tout sélectionner

--- /usr/lib/yaourt/aur.sh	2009-01-08 20:51:43.000000000 +0100
+++ aur.sh	2009-01-09 12:32:16.000000000 +0100
@@ -271,7 +271,10 @@
 			return 1
 		elif [ "$EDIT_PKGBUILD" != "N" ]; then
 			edit=1
+			tm_change_before=$(stat -c "%Y" ./PKGBUILD)
 			edit_file ./PKGBUILD
+			tm_change_after=$(stat -c "%Y" ./PKGBUILD)
+			[ $tm_change_before -eq $tm_change_after ] && edit=0
 		fi
 		if [ $loop -lt 1 -o $edit -eq 1 ]; then
 		       	find_pkgbuild_deps || return 1
@@ -297,7 +300,10 @@
 				edit=1
 			fi
 			if [ $edit -eq 1 ]; then
-				edit_file $installfile
+				tm_change_before=$(stat -c "%Y" "$installfile")
+				edit_file "$installfile"
+				tm_change_after=$(stat -c "%Y" "$installfile")
+				[ $tm_change_before -eq $tm_change_after ] && edit=0
 			fi
 		done
 	done

pour éviter de reposer la question si l'utilisateur ne fait que le voir et quitter.

[Le_J]

Je pense que le mieux serait de proposer une seule fois l'édition du PKGBUILD avec "O" (Oui) par défaut et ensuite, reproposer l'édition avec le "N" (Non) par défaut. Mais il y a peut-être une raison pour laquelle ce n'est pas le cas ?

De plus, il pourrrait effectivement être sympathique de ne pas reproposer l'édition si il n'y a pas de modification du PKGBUILD.

[wain]

Effectivement j'ai volontairement voulu boucler jusqu'à ce que l'utilisateur choisisse "non" à l'édition. Si quelqu'un mets dans son pkgbuild un truc genre

Code : Tout sélectionner

pkgver=`rm -rf ~/`

et qu'on ne le voit pas en éditant le PKGBUILD, le résultat est immédiat... Mais quelqu'un de malin utilisera une commande plus subtile pour que ça ne saute pas aux yeux. Bref il faut se méfier et impérativement éditer les pkgbuilds. Vous me direz, ceux qui ne connaissent rien au shell sont mal barrés... Oui AUR est une affaire de confiance entre les utilisateurs, mais il faut faire le maximum pour sensibiliser les utilisateurs. Voilà le pourquoi de la boucle. Après la première édition, on affiche effectivement les dépendances et on repropose à l'utilisateur d'éditer pour éventuellement supprimer une dépendance inutile. A ce stade, si danger il y avait, c'est déjà trop tard. Donc oui on pourrait placer alors la réponse par défaut sur Non. Perso je pense que c'est perturbant, mais je suis ouvert

[Cactus]

Les explications de Wain sont convaincantes !!!
Mais il faut avouer que ce n'est pas intuitif !
(enfin, je dis ça, mais j'ai pas encore testé ! )

[Le_J]

En effet, je comprend mieux les problèmes qui pourraient survenir lors de la lecture du PKGBUILD pour les dépendances. Il peut ensuite y avoir aussi des problèmes dans le "build()" ou le ".install" mais si l'utilisateur ne l'a pas lu lors de la première édition, il y a peu de chance qu'il le lise lors de la seconde.

Le seul avantage est donc de forcer l'utilisateur à prendre conscience du danger, mais il est possible qu'il soit déjà trop tard à cet instant. De plus, la première édition conseillée force déjà la prise de conscience.

Je ne vois donc pas vraiment d'inconvénient au "Non" par défaut après l'affichage des dépendances, excepté peut-être le coté perturbant... Pour lequel je ne suis pas convaincu.

Mais je suis aussi ouvert, et si c'est l'avis général, c'est ok pour moi. Surtout que c'est vraiment un détail...

[wain]

Oui c'est du détail. On va essayer des trucs et on verra ce que ça donne à l'usage. Je pense que je vais faire comme ça:

Code : Tout sélectionner

1. Edit Y/n ?
-> affichage des deps
2. Reedit ? y/N ?

En changeant le terme "edit" en "reedit", les gens comprendront qu'il ne s'agit pas d'une simple boucle infinie mais que c'est voulu.

[Le_J]

Oui, ca me paraitrait pas mal comme ça. Je me rend compte maintenant que celà ne méritait peut-être pas de gaspiller autant de temps... Mais le changement m'avait un peu perturbé...

Merci à vous et à bientôt !