[YAOURT] fonctionnalité

Annonces, dépannage, évolution du projet yaourt
Clark
archer
Messages : 142
Inscription : dim. 01 juil. 2007, 15:41

Message par Clark »

L'intérêt, c'est quand tu as une mise à jour de paquet (x.y.z-3 vers x.y.z-4) mise sur testing : un menu interactif dans yaourt te permettrait de l'installer sans danger, puisque tu vois tout de suite que c'est un "lifting" à deux balles, qui peut-être corrigera le petit bug qui te pourrit la vie.
Par contre, si tu vois une nouvelle version (x.w.u-9 vers x.x.0-1), tu peux choisir de ne pas l'installer par testing et attendre qu'elle passe dans un dépôt stable.
Ainsi, tu peux mettre testing en seconde position ou première position dans la liste des paquets (en fonction du degré de stabilité que tu veux pour ton système) et choisir finement à la volée sans éditer de liste noire les paquets ou types de paquets instables que tu souhaites installer.
Avatar de l’utilisateur
wain
Maître du Kyudo
Messages : 1854
Inscription : ven. 11 août 2006, 19:15
Localisation : Nancy (54)

Message par wain »

Clark a écrit :L'intérêt, c'est quand tu as une mise à jour de paquet (x.y.z-3 vers x.y.z-4) mise sur testing : un menu interactif dans yaourt te permettrait de l'installer sans danger, puisque tu vois tout de suite que c'est un "lifting" à deux balles, qui peut-être corrigera le petit bug qui te pourrit la vie.
Sauf que si x.y.z-4 est une dépendance d'un autre paquetage, tu as de grandes chances de casser l'autre paquetage en l'installant. En fait, ça ne marcherai que dans le scénario suiva,t:
Une nouvelle version d'un soft arrive dans [testing], mais cette version plante parceque sa dépendance X n'a pas été recompilée. Quelques heures plus tard, la dépendance X est recompilée et change de numéro de release. Là oui, on peut avoir envie de n'installer que cette mise à jour "lifting à deux balles" (très bon terme). Mais pourquoi se priver d'autres mises à jour de logiciels dans la foulée ? Si on a vu la maj grâce au flux, autant faire directement un yaourt -S X.
Clark a écrit :Ainsi, tu peux mettre testing en seconde position ou première position dans la liste des paquets (en fonction du degré de stabilité que tu veux pour ton système) et choisir finement à la volée sans éditer de liste noire les paquets ou types de paquets instables que tu souhaites installer.
Sauf qu'actuellement le -Su de pacman n'est pas capable de détecter une nouvelle version dans un dépôt classé plus bas.
On ne verra jamais avec -Su:

Code : Tout sélectionner

Mise à jour:
extra/kde
testing/kde
C'est peut-être un truc faisable dans yaourt par contre.
Clark
archer
Messages : 142
Inscription : dim. 01 juil. 2007, 15:41

Message par Clark »

wain a écrit : Sauf que si x.y.z-4 est une dépendance d'un autre paquetage, tu as de grandes chances de casser l'autre paquetage en l'installant...
Ben je ne vois pas pourquoi : le fait que ce paquet soit toujours numéroté x.y.z ne doit justement rien casser, le passage de la release 3 vers 4 n'est censé corriger que des bugs si j'ai bien compris, sauf si le mainteneur s'est gauffré bien sûr. Mais je veux bien reconnaître que ça n'a pas trop d'importance pour les releases.
wain a écrit : Sauf qu'actuellement le -Su de pacman n'est pas capable de détecter une nouvelle version dans un dépôt classé plus bas.
Peu importe on parle bien de yaourt là ? Avec lui tu affiches déjà le dépôt d'origine des mises à jour, c'est juste ce qu'il faut : ça permet de choisir des paquets testing qui t'intéressent ou de passer la main si tu préfère attendre que le paquet "mûrisse" un peu.
Avatar de l’utilisateur
wain
Maître du Kyudo
Messages : 1854
Inscription : ven. 11 août 2006, 19:15
Localisation : Nancy (54)

Message par wain »

Clark a écrit :le fait que ce paquet soit toujours numéroté x.y.z ne doit justement rien casser, le passage de la release 3 vers 4 n'est censé corriger que des bugs si j'ai bien compris, sauf si le mainteneur s'est gauffré bien sûr. Mais je veux bien reconnaître que ça n'a pas trop d'importance pour les releases.
Bein ça arrive par exemple suite aux maj de gcc lorsque les devs recompilent pleins de pkgs et que seul le numéro de release est incrémenté. Là si tu met à jour que la lib mais pas l'appli t'as des segfault (par exemple entre libetpan et claws-mail).
Clark a écrit :
wain a écrit :Sauf qu'actuellement le -Su de pacman n'est pas capable de détecter une nouvelle version dans un dépôt classé plus bas.
Peu importe on parle bien de yaourt là ? Avec lui tu affiches déjà le dépôt d'origine des mises à jour, c'est juste ce qu'il faut : ça permet de choisir des paquets testing qui t'intéressent ou de passer la main si tu préfère attendre que le paquet "mûrisse" un peu.
oui mais tu parlais de choisir les packages de testing lorsque le dépôt est en dessous de core/extra dans la conf si j'ai bien compris. Et dans ce cas, si un package est upgradable dans testing mais que extra ou core est en premier, la maj ne proposera pas ce paquetage de testing. Pour rappel, yaourt utilise la liste de "pacman -Su". Pour changer ce comportement, ça demande de grosses modifs.

Je pense que je vais simplement ajouter une option qui balance toute la liste des paquetages dans un fichier texte. Ce fichier texte sera ouvert dans l'éditeur par défaut et il suffira de commenter/décommenter les lignes les packages qu'on souhaite ou non installer. Comme ça chacun pourra rapidement faire ce qu'il veut.
Clark
archer
Messages : 142
Inscription : dim. 01 juil. 2007, 15:41

Message par Clark »

wain a écrit : Bein ça arrive par exemple suite aux maj de gcc ...
OK
wain a écrit : oui mais tu parlais de choisir les packages de testing lorsque le dépôt est en dessous de core/extra dans la conf si j'ai bien compris.
Euh non, c'était le contraire ;)
wain a écrit :Je pense que je vais simplement ajouter une option qui balance toute la liste des paquetages dans un fichier texte. Ce fichier texte sera ouvert dans l'éditeur par défaut et il suffira de commenter/décommenter les lignes les packages qu'on souhaite ou non installer. Comme ça chacun pourra rapidement faire ce qu'il veut.
C'est effectivement le plus simple. On verra ce que ça donne à l'usage.

Au fait, merci pour ton excellent travail ;)
Avatar de l’utilisateur
wain
Maître du Kyudo
Messages : 1854
Inscription : ven. 11 août 2006, 19:15
Localisation : Nancy (54)

Message par wain »

La modification est dispo dans yaourt-git. Le code a pas mal bougé, donc n'hésitez pas à me signaler tout problème.
Avatar de l’utilisateur
Calimero
Elfe
Messages : 692
Inscription : ven. 02 mai 2008, 18:16
Localisation : Nantes (44)

Message par Calimero »

Voici le premier : quand je fais yaourt -Q atl2, par exemple, ça affiche la version en vert, et comme elle est en dernier, après toute la suite dans l'invite de commandes est verte. Tout est vert, jusqu'à ce qu'un programme réutilise les couleurs et remette au blanc après son passage.

Il ne manquerait pas l'équivalent d'un "</color>", pour ainsi dire ?
Mes trucs : LiveCD http://ctkarch.org/ ; Blog, guide Arch, etc… http://calimeroteknik.free.fr/
In a world without walls and fences, who needs windows and gates ?
Avatar de l’utilisateur
Calimero
Elfe
Messages : 692
Inscription : ven. 02 mai 2008, 18:16
Localisation : Nantes (44)

Message par Calimero »

Ça ne me le fait qu'en console virtuelle. (Ctrl+Alt+F1 par exemple)
Dans Konsole, tout va presque bien (seul le curseur verdit jusqu'à ce que j'appuie sur backspace)

Tu avais vu ça, wain ?

Un petit exemple en image :

Image

(ouais j'suis un gros naze, je sais même pas faire des captures d'écran de framebuffer)
Mes trucs : LiveCD http://ctkarch.org/ ; Blog, guide Arch, etc… http://calimeroteknik.free.fr/
In a world without walls and fences, who needs windows and gates ?
Avatar de l’utilisateur
wain
Maître du Kyudo
Messages : 1854
Inscription : ven. 11 août 2006, 19:15
Localisation : Nancy (54)

Message par wain »

ouep c'est corrigé dans ma branche git. Je mettrais ça en ligne ce soir.

edit: voilà c'est dispo dans yaourt-git
Répondre