[YAOURT] fonctionnalité
[YAOURT] fonctionnalité
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.
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.
- lenglemetz
- Chu Ko Nu
- Messages : 307
- Inscription : dim. 27 mai 2007, 22:26
- Localisation : Marmande
- Contact :
- wain
- Maître du Kyudo
- Messages : 1854
- Inscription : ven. 11 août 2006, 19:15
- Localisation : Nancy (54)
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 ?
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 ?
s/pacman/yaourt/g c'est ARCHi clair ! => http://archlinux.fr/
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.
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.
- wain
- Maître du Kyudo
- Messages : 1854
- Inscription : ven. 11 août 2006, 19:15
- Localisation : Nancy (54)
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..
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..
s/pacman/yaourt/g c'est ARCHi clair ! => http://archlinux.fr/
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.
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.
Devenez colocataire de Rootards.
##hippie irc.freenode.net
##hippie irc.freenode.net
- wain
- Maître du Kyudo
- Messages : 1854
- Inscription : ven. 11 août 2006, 19:15
- Localisation : Nancy (54)
bonne idée ouiAddiKT1ve a écrit :Une petite chose... Je propose de ranger les paquets par dépôt :
s/pacman/yaourt/g c'est ARCHi clair ! => http://archlinux.fr/
Pas mal, avec aussi peut-être, au lieu de "Continue install", mettre une question à choix multiples :wain a écrit : 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..
- 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).
- wain
- Maître du Kyudo
- Messages : 1854
- Inscription : ven. 11 août 2006, 19:15
- Localisation : Nancy (54)
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:
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.
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
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.
s/pacman/yaourt/g c'est ARCHi clair ! => http://archlinux.fr/
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 ?
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
- Maître du Kyudo
- Messages : 1854
- Inscription : ven. 11 août 2006, 19:15
- Localisation : Nancy (54)
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.Clark a écrit :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 ?
T'aurai un exemple concret qui montre bien l'utilité du truc ?
s/pacman/yaourt/g c'est ARCHi clair ! => http://archlinux.fr/