Archlinux.fr [Forums] • Voir le sujet - [aur] aur-search *new*

farvardin · **Inscrit le:** Sam 29 Mars 2008, 23:56 **Messages:** 1082

pourquoi aur-search n'est pas sur AUR ??

wain · **Publié:** Jeu 04 Mars 2010, 01:16

benjarobin a écrit:

More... Cette commande n'est pas dépréciée ?
Sinon si tu avais fait

Code:

yaourt nvidia | less

tu n'aurais pas eu de problème.
Puis tu récupères le nom du paquet, ferme tout. Puis

Code:

yaourt -S --aur le-nom-du-paquet

sinon il y a yaourt -Ss pour lancer la recherche seule. Pour l'instalation --aur n'est pas nécessaire. Cette option permet uniquement de forcer la compilation depuis AUR lorsque le paquet est disponible à la fois sur un dépôt non officiel et sur AUR.

@mimas: je rejoins tuxce, si tu pouvais y intégrer l'accès à libalpm ça serait top ! :bravo:

Refuznik · **Inscrit le:** Dim 22 Nov 2009, 18:06 **Messages:** 445

Pas de problème pour -Ss je l'utilise régulièrement l'équivalent de yum search mais c'était le less à la fin que j'avais pas intégré.

mimas · **Publié:** Jeu 04 Mars 2010, 15:58

Que veux-tu Wain ?

Intègre-je alpm dans aur-search pour donner l'information que le paquet est installé (base de local/) ?
Fais-je un alpm-search qui va compléter aur-search en regardant dans les base de sync/ quels paquets correspondent au critère de recherche ?

tuxce · **Inscrit le:** Mer 12 Sep 2007, 16:03 **Messages:** 6423

perso, je verrais plus une commande pour du parsing, genre:

Code:

aur-search [-s,--sep=separator] [-n,--node={name,version,desc,...}] critère de recherche

qui ressortirait chaque résultat sur une ligne sans formatage pour que ça puisse être parsable par awk ou autre.
et de même pour alpm:

Code:

alpm-query [-q,--query={conflict,replace,provide,depend,own...}] critère de recherche

pour pouvoir depuis un wrapper proposer des soluces, ou tout simplement présenter un résultat sous la forme souhaitée, un exemple serait pour yaourt qui s'en remet à makepkg de déterminer avant un conflit particulier pour proposer la suppression avec -Rd

alors peut être fusionner les 2, je sais pas, enfin c'est des pistes...

mimas · **Publié:** Ven 05 Mars 2010, 00:10

Ok.

J'ai commencé. Pour l'instant le programme cherche des paquets dans toutes les bases du disque (local + sync). Il faut que je regarde comment gérer les requêtes autre que les dépendances car elles sont présentes uniquement dans la base local. Pour expliquer, si je fais alpm-query --show-conflicts tux, seuls les paquets présents dans local sont susceptibles d'afficher quelques choses car eux seuls contiennent cette information.

Note à moi (parce que je pense à ça et ne fais pas autre chose).
Je vais faire des flags de type --conflicts qui permettront d'afficher les conflits avec le paquets en arguments et des flags du type --show-conflicts pour afficher les conflits du nom de paquet passé en argument. Je vais aussi faire un flag --search qui permettra de lister les paquets dont le nom contient le nom passé en argument (et les informations du type --show-X).

Ça devrait couvrir un large panel de requêtes.

Puis un flag --raw pour un affichage brute (on parlera de ça plus en détail).

Rhô, j'ai du boulot.

tuxce · **Inscrit le:** Mer 12 Sep 2007, 16:03 **Messages:** 6423

mimas a écrit:

Il faut que je regarde comment gérer les requêtes autre que les dépendances car elles sont présentes uniquement dans la base local. Pour expliquer, si je fais alpm-query --show-conflicts tux, seuls les paquets présents dans local sont susceptibles d'afficher quelques choses car eux seuls contiennent cette information.

(à moins que je n'ai pas compris ce que tu dis) non, elles sont présentes dans la base sync aussi, par exemple, ce programme:
http://pastebin.archlinux.fr/378905
sous conflict.c par exemple:

Code:

$ gcc -g conflict.c -o conflict -lalpm
$ ./conflict extra rake qemu
0
+ ruby
+ qemu-kvm

(fais pas gaffe au 0 et les +)
en gros ça pourra remplacer tous les grep à répétition sur l'arborescence de la base (en plus, on recherche pas les conflits dans yaourt

(enfin si, mais à la demande))

si t'as un git ou autre (voire même à le mettre sur http://gitweb.archlinux.fr) je suis intéressé par un soft de ce genre et peux participer

mimas · **Publié:** Ven 05 Mars 2010, 13:22

C'est moi qui raconte des bêtises. Je ne sais pas pourquoi j'étais parti sur une configuration différentes des fichiers desc, depends et files.

J'ai quelques trucs à faire avant de mettre le programme en ligne, pourquoi pas sur le git d'archlinux.fr. Ça ne prendra que quelques jours.

mélodie · **Publié:** Mer 31 Mars 2010, 00:17

aur-search ! aur-search !

Et puis pourquoi "package-query" est-il une dépendance obligatoire de yaourt ? :shock:

mimas · **Publié:** Mer 31 Mars 2010, 17:14

Une nouvelle version de aur-search.

*Features*
- recherche multicritères
- suppression des entrées signalées obsolètes.
- tris divers.
- affichage de la version installée si un paquet d'AUR est installé dans la babasse.

Astuce pour la recherche multicritère.

Si on sélectionne tri sur le nom (option -n), le premier terme de recherche sert à filtrer le nom (bin ouais, quoi ?) et les tous autres termes doivent être présents dans la description. Dans le cas contraire tous les termes de recherche doivent être présents dans la description.

Par exemple :

aursearch -n lua library.

affichera tous le paquets dans le nom comporte lua et la description comporte library.

Ouaich, trop simple.

aursearch car game.

Affichera tout les paquets de AUR dont la description comporte car et game.

La recherche est insensible à la casse.

Le lien : http://mimarchlinux.googlecode.com/file ... 0.1.tar.gz

CroK

Je viens de lire ce post, c'est vraiment bien comme programme.

Rapide, clair.. Mes félicitations !

Feng · **Inscrit le:** Mer 07 Avr 2010, 20:19 **Messages:** 270

Slt,

J'ai voulu essayé aur-search 0.1-1 , malheureusement j'ai une erreur à la compilation :

Code:

==> Lancement de build()...
cd libjson-0.6; make
make[1]: entrant dans le répertoire « /tmp/yaourt-tmp-feng/aur-aur-search/src/aur-search/libjson-0.6 »
gcc -march=x86-64 -mtune=generic -O2 -pipe -c -o json.o json.c
ar rc libjson.a json.o
gcc -march=x86-64 -mtune=generic -O2 -pipe -L. -Wl,-soname -Wl,libjson.so.0.6.0 -shared -o libjson.so.0.6.0 json.o
/usr/bin/ld: json.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
json.o: could not read symbols: Bad value
collect2: ld a retourné 1 code d'état d'exécution
make[1]: *** [libjson.so.0.6.0] Erreur 1
make[1]: quittant le répertoire « /tmp/yaourt-tmp-feng/aur-aur-search/src/aur-search/libjson-0.6 »
make: *** [libjson-0.6/libjson.a] Erreur 2
    Abandon...

Code:

[feng@firemoon ~]$ uname -a
Linux firemoon 2.6.34-ARCH #1 SMP PREEMPT Sat Jun 19 00:07:49 CEST 2010 x86_64 Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz GenuineIntel GNU/Linux

Une librarie C json est disponible sur AUR ( json-c ) , pourquoi ne pas l'utiliser plutôt que de l'inclure dans le paquet ??

mimas

Il doit manquer une option pour que ça compile sur du 64 bits. Comme le message l'indique, essaie d'ajouter -fPIC à la ligne kivabien dans le Makefile.

mimas

Mise à jour du programme (http://mimasgpc.free.fr/files/aur-search-0.2.tar.gz) ou sur http://code.google.com/p/mimarchlinux/downloads/list

J'ai corrigé deux gros bugs sur la récupération du json sur AUR : il y a enfin la liste complète des entrées de AUR et plus d'erreur d'encodage ; libfetch est une bibliothèques pleine de surprises.

Le liens vers le répertoire de AUR est affiché, on peut donc accéder rapidement aux PKGBUILDs qui nous intéressent.

Code:

aur-search -n aur lua
    * aurstate (ver. 20091120-1 / vot. 2)
       Desc : Lua script to help maintaining AUR packages up to date
       URL  : ftp://catwell.info/code/aurstate
       Files: http://aur.archlinux.org/packages/aurstate/

    * aur-repo-check (ver. 20100325-1 / vot. 1)
       Desc : Lua script to compare the state of a repository to AUR
       URL  : ftp://catwell.info/code/aur-repo-check
       Files: http://aur.archlinux.org/packages/aur-repo-check/

J'ai dans l'idée de mettre un filtre d'exclusion (préfixé d'un - ou !), on verra ça plus tard. Il y a tellement d'autres programmes qui font plus encore.