[YAOURT] fonctionnalité

[seginus]

Archers, Archéseuses, bonjours à vous.

Je ne pense pas souvent à venir ici, mais vu que l'on m'y a fait pensé, je vais prendre ma plus belle plume pour vous écrire.
Tout d'abord, tout à commencé tout à l'heure après un « yaourt -Suy ».
Là, grosse mises à jour. Une petite centaine de paquets. Je me suis dit : « alors qu’y at-il de neuf ? ». Et là, je me suis rendu compte que ce n’est pas évident de voir les « vrais » mises à jours.
Alors voilà mon idée :

faire ressortir par des couleurs dans yaourt le type de mises à jour :
— Les mises à jour de versions
— Les mises à jour secondaires
— Les mises à jour du mainteneur

Cela je pense devrait prendre une dizaine de lignes. on regarde le chiffres qui change entre les deux versions, et suivant si c'est avant le premier point, après ou après le tiret, on adapte la couleur en conséquence.

Et vous ? cette fonctionnalité vous intéresse-t-elle ?
Quelqu'un a-t-il les connaissances nécessaires en bash pour faire cela sans y passer une semaine ?
Cela vaut-il le coup de demander à Wain si il peut regarder ce qu'il peut faire ?

Voilà, c’était ma pensé du jour. À bientôt pour de prochaines aventures.

[AddiKT1ve]

Excellente idée, très certainement aisément grâce à yaourt.

[lenglemetz]

!fouet seginus, c'est bien parce que tu passes pas souvent sur le forum que j'édite ton titre :p

sinon oui l'idée est très simpa, reste a voir le jugement du maître yaourt

[AddiKT1ve]

Hallelujah

[wain]

ouep c'est une bonne idée. Je propose d'afficher le résultat sous la forme de 3 sections car tout le monde n'utilise pas les couleurs

1. En blanc les mises à jour du paquetage (alias mise à jour du mainteneur où seul le pkgrel change)

2. En bleu/vert les mises à jour de versions (cette fois la modif de pkgver)

3. En rouge, les nouveaux paquetages installés (les pièces rapportées par le jeu des dépendances)

Ce qui serait l'occasion de rajouter la fonction dont je rêve depuis longtemps pour les serveurs: ne mettre à jour qu'avec les maj des mainteneurs.

Ca vous conviendrait ?

[AddiKT1ve]

Owi \o/

[cycyx]

Formidable !

Bon, maintenant, tu attends quoi pour le faire ? :p

[AddiKT1ve]

[seginus]

Très bien, mais ne pourrait-on pas différencier aussi les mises à jours « importante » des mises à jours de correctifs.
Je veux dire par là 1.1.5-1 -> 1.2.1-1 d'une couleur, mais 1.1.5-1 -> 1.1.6-1 d'une autre couleur ?

ça permettrai là de voir les applications où il devrait à priori y avoir de nouvelles fonctionnalités.

(couleur ou tout autre moyen)

Bravo en tout cas à Wain pour son formidable travail.

[mélodie]

On va en voir de toutes les couleurs...

[Alplob]

Cette idée est très intéressante !

[marc[i1]]

Que de choses à faire et si peu de bras pour aider !

[wain]

J'ai fait ça pour l'instant:


Les paquetages sont scindés en 3 groupes et on y voit le dépôt d'origine (toujours intéressant ça). Je voudrais ajouter un affichage détaillé avec l'option "V" qui donnerai plus d'infos comme la description, la raison de l'installation (dépendance du pkg x ou y) etc...
S'il y a des choses que vous aimeriez avoir sous les yeux au moment d'une upgrade, c'est le moment de le dire

Je pensais aussi à la possibilité d'ouvrir la liste des pkgs à upgrader dans un fichier pour qu'on puisse commenter ou supprimer à la main ceux qu'on ne veut pas mettre à jour. Ca éviterait de devoir killer puis relancer yaourt -Su --ignore pkg1 --ignore pkg2 etc..

[AddiKT1ve]

C'est impressionnant ce que l'on gagne en visibilité, merci wain Release the hounds!

Une petite chose... Je propose de ranger les paquets par dépôt :

core / Paquet 1
core / Paquet 2
core / Paquet 3
extra / Paquet 1
extra / Paquet 2
extra / Paquet 3

etc.

[wain]

Une petite chose... Je propose de ranger les paquets par dépôt :

bonne idée oui

[Clark]

Je pensais aussi à la possibilité d'ouvrir la liste des pkgs à upgrader dans un fichier pour qu'on puisse commenter ou supprimer à la main ceux qu'on ne veut pas mettre à jour. Ca éviterait de devoir killer puis relancer yaourt -Su --ignore pkg1 --ignore pkg2 etc..

Pas mal, avec aussi peut-être, au lieu de "Continue install", mettre une question à choix multiples :
- continuer (= y ou 1 ou enter) ;
- voir les détails (= v ou 2) ;
- éditer la liste des paquets (= e ou 3) ;
- n'installer que les "package upgrade" (=4) ;
- n'installer que les "software upgrade" (=5) ;
- ne pas continuer (= n ou 6).

[PierreAd]

Je trouve cette idée vraiment très bonne !

Merci au passage @wain pour le taf fourni, yaourt est déjà un outil excellent qui ne cesse de s'améliorer

[wain]

Merci à vous

Un ptit mot au sujet de la possibilité de n'installer que les mises à jour d'une catégorie:
J'ai essayé pendant un temps de garder un système dans un état stable en ne mettant à jour que les releases de paquetages (et non les maj de logiciels). Seulement voilà, Arch est une distro qui ne fonctionne que si les programmes et toutes leurs dépendances sont bien à jour.

Prenez l'exemple suivant:
Si openssh passait en version 5.1 et que yaourt -Su, proposait ça:

Code : Tout sélectionner

==> Mise à jour des paquetages seulement (nouvelle release):
core/openssl version 0.9.8h release 3 -> 4

==> Mise à jour des logiciels (nouvelle version):
core/openssh 5.0p1-2 -> 5.1-1

Dans ce cas, si on mettait à jour seulement openssl (dépendance de ssh) sans mettre à jour openssh, alors ssh marcherait plus plus: (genre libssl.so.0.9.8 not found).

Bref on est quand même sur des oeufs lorsqu'on ne met à jour qu'une partie des paquetages. J'ai pas trop envie d'inciter les gens à faire ça. Pour des cas particulieurs on peut toujours jouer avec IgnorePkg dans pacman.conf ou --ignore.

[Clark]

Effectivement, dans le cas "normal", c'est sans doute un mauvaise idée. Mais je me permets de maintenir l'idée pour le cas particulier où le dépôt testing est activé et apparaît en premier dans la liste des dépôts.

Une apparition conditionnelle du menu que je te propose et de ta possibilité de n'installer que telle ou telle catégorie de m-a-j de paquets est-elle possible uniquement si testing est utilisé avant un des dépôts stables ?

[wain]

Effectivement, dans le cas "normal", c'est sans doute un mauvaise idée. Mais je me permets de maintenir l'idée pour le cas particulier où le dépôt testing est activé et apparaît en premier dans la liste des dépôts.

Une apparition conditionnelle du menu que je te propose et de ta possibilité de n'installer que telle ou telle catégorie de m-a-j de paquets est-elle possible uniquement si testing est utilisé avant un des dépôts stables ?

Moi je veux bien faire, du moment que je comprend l'intérêt. Mais mettre à jour une librairie à partir d'une nouvelle release de Testing me semble risqué si on ne met pas à jour l'application qui en a besoin dans la foulée.
T'aurai un exemple concret qui montre bien l'utilité du truc ?