Vaykadji :
L'idée n'es pas mauvaise : je plusois.
Mais je pense vraiment que ça dois encore mûrir avant de se lancer tête baissé.
Je note quand même un léger avantage au ppa sur les .exe ou autre : tu cherches à un endroit : launchpad... c'est donc moins aventurier.
Maintenant, la réalisation est tout autre.
* Dans un 1er temps : définir ce qu'apporte les ppa et qui est concerné (la cible)?
De ce que j'en comprend, les cibles sont :
* les devs et bétas testeurs (ne pas oublier que il n'y a pas que des logiciels mais aussi des libs)
* les personnes *pressés* d'avoir une version qui n'est pas encore disponible dans leur version
* l'installation de paquets non supporté
* j'en oubli sans doute
Les ppa sont finalement un grand hangar que met Canonical à dispo mais sans vérifier : la qualité, la sécurité etc.
Ça ne concerne bien évidement que des personnes bien informé des possibles risques encourus : instabilité, rootkit...
Une bonne question à ce poser : trop simplifier la procédure ne risque-t-elle pas de provoquer de mauvaises utilisations?
Par exemple, un utilisateur *moyen* se servant de cet outil à tord et à travers risque d'avoir une liste de dépôts indigestes et chaque "apt-get update" et ça lui prendra un temps considérable.
Perso, j'ai pas envie que mon installation d'un ppa soit transparente : si j'installe un programme contenu dans un ppa encore inexistant sur ma bécane, je veux être averti.
* Partir sur une base de donnée "doublon" de launchpad entrenu à la mano... c'est à mon sens l'échec assuré.
Les mainteneurs aussi zelés soient-ils vont se lasser de mettre à jour, c'est certain : y'a qu'à voir sur le wiki les efforts considérables pour lister des procédures en fonction des versions d'ubuntu...
* comme sous-entend "amj", derrière la logithèque ou autre GUI, il y a une ligne de commande type "apt".
L'idée serait soit de créer un programme cli en + et/ou de surchoucher "apt".
Il vaut mieux créer un truc qui peu être transposable partout (bas niveau) que de ce limiter à la logithèque.
En plus, ça pourrait conduire à un "lens" sous unity...
* qui est prioritaire? Si on fait une recherche sur gimp par exemple et qu'il y a 4 versions en conflit (je simplifie volontairement :
https://launchpad.net/ubuntu/+ppas?name_filter=gimp) :
la version officiel et 3 ppa de gimp... on fait quoi? On est obligé de faire du questions/réponses.
La encore, les non initiés risquent d'être dérouté par la complexité.
Pour résoudre tous les soucis pré-cités par "amj" et "Hizoka", je ne vois qu'une solution : utiliser l'API de launchpad:
https://help.launchpad.net/API
et
https://help.launchpad.net/API/Examples
(ouais : faut programmer en python).
L'idée serait donc de récupérer la liste de paquets, sa description, le ppa correspondant et sa description également.
Je ne peux malheureusement pas t'affirmer que cette API sera suffisante. Faudra potasser/tester pour ça.
Si c'est pas suffisant, faudrait utiliser un truc à la ppasearch : parser du HTML pour arriver à tes fins. (en python, y'a la lib BeautifulSoup qui est magique pour ça)
Tu peux bien évidement t'inspirer de ppasearch mais je conseil de repartir sur une base saine car ce script n'est plus maintenu depuis 3 ans tout de même.
Ça réduira les soucis de latence mais il reste toujours possible de les réduire d'avantage en mettant en place un serveur proxy.
Voilà sur les grandes lignes à quoi ça pourrait ressembler :
* BDD à fort traffic, noSQL de préférence tel que Redis qui peut être contenu en ram.
* caching avec varnish
* chaque nouvel requête procède ainsi : interrogation de launchpad et sauvegarde en cache de la réponse.
* mise à jour des entrée de la base régulière (cron) : on vérifie que le paquet correspond toujours à tel ppa : si oui, on change, sinon, on met à jour la base.
* cache côté client (une fois que le système à une base déjà bien étoffé) : proposer côté client une mini-base des logiciels les + populaire afin d'éviter de passer par le serveur proxy dans les cas les plus courant.
Ah, si : il y aurait une autre solution : créer un dépôt incluant tous les ppa et qui se mettrait à jour régulièrement. (c'est un peu le serpent qui se mord la queue)
Il faudrait trouver une solution bien évidement sur les noms doublons : du genre "gimp_ppa:ferramroberto" pour le paquet gimp provenant du ppa ferramroberto et convertir les paquets automatiquement demanderais sans doute de l'investissement mais ça ne serait pas impossible.
Maintenant, j'ai aucun recul sur un "apt-cache search" sur une liste de plusieurs centaines de milliers de paquets. (t'en a 40 000 de base + tous ceux des ppa)
Faudrait faire des benchs par la suite pour voir si c'est raisonnable...
Bref, on voit bien que l'initiative devrait plutôt venir de Canonical.
Maintenant, il y a déjà eu d'autres efforts de la communauté qui ont donnés des idées à Canonical donc c'est pas forcément un coup d'épée dans l'eau!
PS : Je me suis aussi demandé pourquoi il était aussi simple d'ajouter un programme en 1 clic : apt://libreoffice-kde et qu'il n'existe pas un équivalent pour
installer 1 ppa ou mieux ppa + une liste de logiciels.
un truc genre "[url=addrepo://ferramroberto/gimp?apt=gimp,gmic]addrepo://ferramroberto/gimp?apt=gimp,gmic[/url]" te fais automatiquement :
sudo add-apt-repository ppa:ferramroberto/gimp
sudo apt-get update
sudo apt-get install gimp gmic
Comme toujours : si tu penses t'engager sur un projet (et qu'en plus tes connaissances en prog sont maigres), il faut voir *petit* et définir un cahier des charges rudimentaires.
Si tu atteints tes objectifs rapidement, ça te boostera.
Et puis, si c'est open-source : un dépôt
git de tes efforts est bien venu.
Tu pourras revoir ton soft sous un nouvel angle : ces défauts de conception par exemple et rectifier le tir en refaisant de 0.
Faut surtout pas en avoir peur, c'est hyper constructif car ça permet de se concentrer sur les grandes lignes et non sur les détails. (ou on s'englue rapidement)
