Reprise du message précédent :

Perso, vu le faible nombre de paquets AUR que j'utilise (j'essaie de minimiser ce nombre), je n'ai pas trouvé de nécessité à utiliser un outil dédié (qui d'ailleurs proviendrait nécessairement de AUR).
Pour savoir si il y a des màj (ce qui est rare dans mon cas), j'ai simplement ajouté un git fetch --dry-run à mon script de màj quotidiennes, et ensuite je fais mon makepkg à la main.
Comme ça au moins, je maitrise ce qui s'installe sur mon système, parce que sur AUR, il peut quand même y avoir tout et n'importe quoi à la base…

Comme Kajoux j'utilise aucun gestionnaire de paquets AUR, car je pars du principe que ce dépôt ne remplit pas les critères de sécurité/fiabilité, et donc qu'il n'est pas raisonnable de l'utiliser pendant une durée infinie, ni d'automatiser les choses via un gestionnaire, l'usage du dépôt AUR doit rester exceptionnel, temporaire,

donc j'évite au maximum d'installer un paquet provenant du dépôt AUR, et quand je n'ai pas le choix alors j'inspecte d'abord le fichier PKGBUILD pour voir si le mainteneur a respecté les conventions de packaging (disponibles sur le wiki d'archlinux), puis je lis les commentaires des utilisateurs, si c'est Ok alors je crée le paquet avec l'utilitaire makepkg,

il m'arrive parfois aussi de créer mon propre PKGBUILD, sans passer par AUR, mais c'est rare, car la plupart du temps le logiciel existe déjà dans les dépôts stables,

grosso modo l'inconvénient de ces outils à la yaourt/yay/pakku c'est qu'ils ont tendance à faire oublier à l'utilisateur que ces paquets AUR n'ont pas vocation à être pérennisés dans le système, ces paquets sont là pour dépanner, en attendant leur arrivée dans les dépôts "stables", ils ne faut pas que le dépôt AUR fasse partie de la routine de mise à jour du système (certaines paquets AUR peuvent entrer en conflit avec un paquet provenant des dépôts stables, et exiger la désinstallation du paquet au profit de la version AUR, ou bien un mainteneur qui a fait un PKGBUILD crade, avec des fichiers *.postinstall abusifs).

oui enfin on peut, et on doit, jeter un œil au pkgbuild... et les votes sont bien utiles pour minimiser les risques
et ne pas oublier que beaucoup de paquet aur finissent dans le dépôt community.  
et yaourt n'est pas en disgrâce, il n'est plus maintenu, nuance

+ pour yay.

Celui dont je parlais et qui a été "abandonné" (en fait, le dev le garde pour lui.), c'était Pacaur.  
Quant à Aura, la version 2.0 est sorti.

Pas de bol pour quand un logiciel, pourtant connu, et dont tu veux/peux* pas te passer n’est et ne sera vraisemblablement disponible que sur AUR, donc ?
 
* Voir plus bas, dans le cas de pilotes matériels bien particuliers.
 
Faut pas trop tomber dans la psychose non plus, hein. OK, faut être vigilant et ne pas s’en servir n’importe comment, mais quand il s’agit d’outils comme Vivaldi ou Qt4 (eh oui, certains utilisent encore des logiciels qui ont besoin de lui…), on va pas faire dans la généralisation aveugle non plus.
 

Mais pas toujours à jour… J’ai souvenirs de paquets que j’ai dû recompiler moi-même dans leur dernière version car celle des dépôts était en retard, et parfois de plusieurs mois.
 

Ça, c’est toi qui le dis. Encore une fois, il faut voir au cas par cas et on ne peut pas généraliser à tous.
 
Quant à dépanner, ça concernera essentiellement certains pilotes pour des matériels bien spécifiques qui ne peuvent être pris en charge avec les seuls dépôts officiels. Mais là encore, il ne s’agira pas d’une solution temporaire.
 
Et non seulement certains paquets ne seront jamais intégrés aux dépôts (Vivaldi, toujours, même s’il ne faut jurer de rien puisque le mainteneur du PKGBLUID est un Trusted User), mais il arrive aussi que d’autres paquets, pourtant bien intégrés à Community à une époque, soient soudainement relégués ensuite sur AUR. Faut-il se débarrasser d’Inxi au seul motif qu’il a été dégagé des dépôts et ne se trouve maintenant plus que sur AUR ? C’est pas mon avis, tellement cet outil est utile pour avoir un résumé rapide des composants de son ordi.
 

Comme toujours, faut faire un minimum gaffe à ce qu’on installe. Mais c’est pas spécifique à AUR : c’est comme ça partout, sur tous les OS. L’avantage, avec AUR, c’est que si tu sais lire un PKGBUILD, tu auras une chance de ne pas te faire avoir ; alors que des logiciels installables par PPA, des .DEB/RPM/AppImage, ou même des EXE/MSI pour Windows… C’est moins facile.
 

Il n’est plus disponible. Ni sur AUR, ni sur le dépôt tiers d’ArchlinuxFR (où il a été supprimé en premier). C’est encore au-delà de « ne plus être maintenu » : il n’existe juste plus. Et contrairement aux dépôts, AUR ne propose pas d’archive pour retrouver les paquets qui en ont été supprimés, purement et simplement.

oui c'est au-delà... c'est le cas de le dire...
y a un comparatif intéressant sur le wiki anglophone : https://wiki.archlinux.org/index.php/AUR_helpers

Il y en a malheureusement genre Enlightenment (et tout ce qui s'en rattache).  
Le pire étant que, quand tu en parles sur le forum, on te dit que c'est normal d'attendre 6 moislà ou KDE sort quasiment dans la journée alors qu'il fait 1000 fois plus puis le message est supprimé.

J'ai pas tant de chose que ça de AUR:
- Gitflow
- Heroku
- MongoDB
 
Mais c'est le genre de truc où je préfère avoir une m.a.j auto (sinon je ne penserais jamais à le faire).

yay essayé et adopté, yaourt viré, merci
 
Depuis le temps que j'utilisais yaourt, va falloir que je m'habitue à taper yay à la place (mais bon ça fait moins de lettres à taper, c'est tout bénef )

C'est dommage qu'il existe pas sur AUR des flux rss pour chaque dépôt, comme il en existe sur github, pour se tenir au courant des commits (ou alors ça existe mais j'ai pas trouvé).
Moi ça m'irait très bien pour me tenir au courant des mises à jour, ensuite je prends le relai manuellement.

est-ce que ces outils de type yaourt sont capables d'évaluer la qualité de packaging des paquets AUR ? (en terme de respect des conventions de packaging, présence de fichiers *.postinstall suspects, des instructions "rm, ln -s" douteuses  )

avec un algo bien conçu ça devrait être possible, ici on trouve la liste des critères qui permettent de dire si un PKGBUILD respecte les standards de qualité :
https://wiki.archlinux.org/index.ph [...] guidelines

une fonctionnalité d'évaluation automatique permettrait de limiter les dégâts et d'informer l'utilisateur néophyte qu'il est en train d'installer un paquet mal conçu, un peu comme le ferait un antivirus sous windows quand un utilisateur clique sur un fichier "setup.exe" provenant d'un site douteux,

cette évaluation pourrait aussi se faire coté serveur, quand un packageur AUR dépose ses fichiers, ça donnerait une note automatique "respect des standards archlinux", et inciter le packageur amateur à revoir sa copie

J’aimerais quand même avoir des exemples de PKGBUILD d’AUR suffisamment mal fichus (mais pas trop) pour que ça fasse autre chose que planter à la compilation (ça, j’ai parfois connu, oui ; surtout quand c’était moi qui essayais d’en faire un et que je faisais autre chose que changer le numéro de version pour avoir la toute dernière version d’un logiciel qui n’était pas encore dispo de manière plus « officielle » pour Arch).
 
Ensuite, même si c’est pas officiellement supporté, ce qui est mis dessus (au moins une partie) est quand même un minimum contrôlé périodiquement, m’étais-je laissé dire. Sinon, on entendrait sûrement bien davantage parler de paquets vérolés (ce qui peut parfaitement arriver, parce que c’est bien de ça que tu parles, n’est-ce pas), au point qu’AUR serait rapidement fermé. Comme ce n’est pas le cas…

J'ai une bonne dizaine de logiciels qui proviennent d'AUR, donc certains sont assez importants ( compiz... )
Aucun souci.
Et YAY fonctionne très bien  

moi aussi un peu de logiciel, dont notamment le pilote d'imprimante ce qui est bien pratique et firefox-beta aussi.
 
Mais je préfère Pamac en mode graphique. Rechercher un paquet, lire la description, les dépendances, tout se fait naturellement.

Perso j'ai près d'une centaine de paquets qui ne sont pas dans les repos, dont pas mal que j'ai créés/maintenus sur AUR.
 
Je n'ai jamais tenté de m'occuper de paquets sur community, peut-être que j'aurais dû mais le faire sur AUR me suffit. Donc dire qu'AUR n'est que temporaire... mouem.

+10 000
 

+1  
 
Mon yaourt fonctionne encore    
Heureusement qu'on est pas à quelques Mo près :  

 
Premier usage de Yay : bof !  
Lorsqu'un paquet échoue avec yaourt, il reste dans /tmp/yaourt-tmp-$USER/aur-nom_du_paquet ... On peut éditer le PKGBUILD à sa convenance ou corriger pour que le build soit opérationnel. Avec yay, c'est stocké ici : ~/.cache/yay/ . Mais lorsque ça échoue le dossier est vidé donc tout est supprimé. Gênant dans mon cas, certaines sources de mes AUR font plusieurs centaines de Mo.

 
Au début je tapais "yay -Syu", avant de m'apercevoir que "yay" tout seul suffisait.

Ça je l'ai vite intégré, aucun problème

Attends de devoir installer unity-editor  
Avant que je le vide, mon dossier cache yay faisait une cinquantaine de Go

« yay -G nom-du-paquet » te récupère le PKGBUILD et les éventuels fichiers complémentaires (les *.install, *.desktop…) dans un sous-dossier au nom du paquet.

 
C'est configurable, j'ai tout dans /tmp ici, meme si ca ne m'arrange pas toujours.

Je parlais en téléchargement pas du build    

la doc  est sommaire à part le man. Pas de détail sur le fichier de conf dans le man.

Le man parait correct je trouve.

yay, et je force le fait de voir les différences de version (risque de partial upgrade, mais je refuse jamais d'installer un package)

J'ai envie d'investiguer i3, y'en a qui utilisent ça ici ?

oui

Evangélisateur Enlightenment, bonjour je suis là pour vous amenez l'illumination.

Tu fais comment ? C’est justement un truc que j’adorais avec Yaourt et qui me manque sur Yay (il ne le fait que pour AUR, pas pour les dépôts officiels).

Je l'ai utilisé un temps, c'est marrant. Ça prend un peu de temps à enjoliver.
C'est assez cool pour tout ce qui est dévelopement, mais je n'ai pas trouvé incroyable pour une utilisation "média".
 
Je l'ai lâché finalement parce que ça demande quand même un gros investissement (retenir tous les raccourcis claviers, le configurer, etc) mais je suis toujours tenté d'y retourner.

Pas si mal oui finalement yay, ça m'a permis de détecter certains problèmes puisqu'il affiche les  :
 
 -> Missing AUR Packages
 -> Orphaned AUR Packages
 -> Out Of Date AUR Packages  
 

https://github.com/AnarchyLinux/installer/releases
Comme quoi le monde est étrange, Anarchy Linux bouge à fond les ballons depuis quelques mois.

Je vais essayer Yay vu qu'il fait l'unanimité  

Depuis qu’ils ont abandonné l’ambition d’être une distribution forkée d’Arch et se sont recentrés sur l’idée de ne faire qu’un moyen facilité d’installer une Arch Linux tout à fait normale, c’est sûr que ça doit être plus simple à maintenir.

J’ai eu une bizarrerie, ce matin : je sais pas si c’est dû à Yay lui-même (qui a été mis à jour) ou à Go (qui l’a été hier, il me semble), mais je constate maintenant l’apparition d’un dossier « ~/go » dans mon gestionnaire de fichiers.

L’ennui, c’est qu’il n’est pas vide, que certains sous-dossiers sont verrouillés, et que Go est une dépendance de Yay (car ce dernier est écrit dans ce langage). Du coup, j’ose pas supprimer ce dossier (qui « pollue » un peu mon ~, je dois le dire)… Bug de l’empaquetage qui aurait dû mettre ce dossier dans /usr, plutôt ?

EDIT : c’est donc bien la dernière version de Yay qui génère ce dossier « ~/go ». Je l’ai vérifié en désinstallant Yay et Go, et en les réinstallant (d’abord Go en tant que dépendance obligatoire, puis Yay ; mais il semble que je puisse le désinstaller une fois Yay compilé, sûrement peut-on alors supprimer ce dossier ensuite ; et virer Go aussi par la même occasion, car j’en ai besoin que pour les MAJ de Yay ?).

 
+1
Sauf que j'y suis encore dessus  

yay --combinedupgrade --save (la première fois)
Cf https://github.com/Jguer/yay/commit [...] 611f6bdbfc

Justement, je fais un gros usage dev de mon PC...

Le folder ~/go est un probleme du language Go (et du infamous GOPATH). Pendant la compilation de yay il crée (ou ajoute) des choses dans ce folder, normalement tu peux le supprimer après, le binaire n'en a pas besoin pour tourner.

Finalement, hier, je l’ai fait (d’abord le renommer, pour voir). Et comme ça semblait ne rien casser, je l’ai effectivement flingué.
Mais Yay a eu une nouvelle MAJ (9.3.3) ce matin, qui corrige justement ce « bug ».

Je crois bien avoir ce répertoire dû à la compilation d'autres paquets donc je ne sais pas trop quoi en faire là.

`base` group replaced by mandatory `base` package - manual intervention required : https://www.archlinux.org/news/base [...] -required/
 
Il y a des méta-paquets et des groupes maintenant ? C'est nouveau non ? J'étais resté sur l'idée (venant d'ubuntu) que les groupes sous arch étaient plus ou moins le pendant des méta-paquets sous ubuntu.
Par ailleurs il s'agirait d'un méta-paquet "mandatory" ? Ça veut dire que l'install ne serait plus aussi personnalisable qu'avant, où on installait exactement les paquets qu'on voulait ?
Perso j'ai installé direct les groupes base et base-devel, mais bon…

Je vois ça à l’instant. Ah, c’est… surprenant, je dois avouer.

Bah, je pense pas que l’installation soit moins personnalisable : tout le monde devait au moins installer tous les paquets du groupe base (qui est, si j’ai bien compris, le minimum absolu pour avoir un OS fonctionnel) ; et même si j’ai pas vérifié, je crois pas que ce nouveau paquet contienne autre chose que ce qui était déjà dans l’ancien groupe. Ils ont juste tout réuni en un seul gros paquet, c’est tout.

Maintenant, faut voir comment ça va se passer du côté des dérivés comme Manjaro et les forks qui servent d’installeurs comme Anarchy, EndeavourOS, etc.

Bon, ben, je vais m’y coller (ce sera ça de moins à faire demain matin, au lever). En espérant que ça ne casse pas tout…

Non, sous Arch il y a toujours eu les deux méthodes pour regrouper des packages ensembles : groupes et metapackages.
Ce qui est assez mauvais car deux façons de faire + ou - la même chose...
 
C'est bien s'ils font un effort de convergence et que les groupes deviennent des meta packages    
Le problème des groupes c'est que tu ne bénéficies pas des updates si des nouveaux packages sont ajoutés au groupe après que tu l'aies installé, donc les meta packages sont supérieurs sur ce point.
L’intérêt des groupes c'est qu'il était possible de choisir ce qu'on voulait installer parmi les packages du groupe, pas forcément tout.
Je suppose que du coup ils vont découper les anciens groupes en plusieurs meta packages, pour garder une certaine granularité ?
On verra bien.