Sommaire
- La détection du bug
- L'écriture d'un correctif
- La diffusion du correctif
- Les dépôts
- Architecture
- Développement
- Conclusion
Vous connaissez tous Weboob, cet ensemble d'applications exceptionnelles permettant d'interagir avec plus d'une soixantaine de sites web, dans un but d'exportation des données, d'agrégation et recoupement entre plusieurs sites, d'accessibilité pour les personnes malvoyantes, ou encore d'automatisations (plus d'explications ici).
Un problème majeur que l'on rencontre avec Weboob, est l'évolutivité imprévisible des sites web supportés, qui peuvent casser un module si celui-ci n'est pas suffisamment tolérant, ou si le changement est trop conséquent.
Pour réduire le désagrément de l'utilisateur qui ne peut plus utiliser les fonctionnalités qui améliorent sa vie au quotidien, il convient d'être réactif sur trois points :
La détection du bug
Ce premier point est effectué soit par le buildbot (via ses tests journaliers et post-commits), soit par l'utilisateur qui va sagement produire un rapport de bug. Une idée d'amélioration permettant l'envoi automatisé d'un bugreport contenant toutes les informations nécessaires existe dans les cartons, mais ne sera pas abordée.
L'écriture d'un correctif
Chaque module est en principe maintenu par une personne qui l'utilise au quotidien. Malheureusement, il arrive que des modules voient leur mainteneur disparaître sans donner de nouvelles. Il est toujours possible pour un membre de la Core Team dévoué et chômeur d'intervenir rapidement sur un de ces modules, mais ce n'est malheureusement pas toujours possible, notamment en ce qui concerne les modules supportant des sites bancaires.
La diffusion du correctif
Ce point est celui qui va retenir notre attention aujourd'hui.
Jusqu'alors, les modules étant distribués directement avec les sources de Weboob, il convenait de sortir une nouvelle version de l'ensemble du logiciel pour diffuser le moindre correctif.
Pour l'utilisateur, il convenait par simplicité d'utiliser les dépôts Debian de weboob pour bénéficier du système APT afin de mettre aisément à jour les modules. Pour une installation depuis les sources (sans passer par git), c'est plus contraignant.
C'est pourquoi il a été décidé de développer un système de dépôts Weboob (inspiré de celui de tucan) pour distribuer les modules et de gérer leurs mises à jour.
Les dépôts
Concrètement, lorsqu'on installe Weboob, seuls le core et les tools sont présents sur le système.
Dès que l'utilisateur cherche à ajouter un backend, si le module correspondant n'est pas installé, l'application s'occupe d'aller le chercher sur les dépôts, puis l'installe dans son ~/.weboob/.
Pour mettre à jour les modules, l'utilisateur se contentera de taper la commande suivante :
$ weboob-config update
Ça va chercher sur les dépôts si de nouvelles versions des modules installés sont présentes, et si oui les installe.
Ce n'est pas plus compliqué que ça pour l'utilisateur, qui se contente de mettre à jour de temps en temps, ou lorsqu'il rencontre un problème avec un module, pour vérifier si un correctif n'est pas déjà mis à disposition.
Architecture
Un dépôt est un répertoire servi par HTTP qui contient un fichier modules.list, ainsi que, pour chaque module, un .tar.gz (le module lui-même) et un .png (son icône).
Il existe un dépôt pour chaque version de Weboob, avec plusieurs déclinaisons : main et nsfw.
Côté client, chaque utilisateur possède un fichier ~/.weboob/sources.list contenant les liens vers les dépôts.
Par défaut, il contient :
# List of Weboob repositories
#
# The entries below override the entries above (with
# backends of the same name).
·
http://updates.weboob.org/%(version)s/main/
# To enable NSFW backends, uncomment the following line:
#http://updates.weboob.org/%(version)s/nsfw/
·
# DEVELOPMENT
# If you want to hack on Weboob backends, you may add a reference
# to sources, for example:
#file:///home/rom1/src/weboob/modules/
Un éditeur externe peut donc créer son propre dépôt sur lequel il distribue ses propres modules Weboob.
L'outil weboob-repos permet de gérer un dépôt. Lorsqu'un module est mis à jour, sa version (sous forme AAAAMMJJhhmm) est incrémentée.
Développement
Afin de développer des modules sans avoir à les uploader sur un véritable dépôt pour les tester, il est possible de référencer des pseudo-dépôts locaux.
Pour ce faire, il suffit de spécifier le chemin vers le répertoire contenant les modules de cette manière :
file:///path/to/modules/
Après un weboob-config update, les modules qui s'y trouvent sont utilisables directement.
Contrairement aux dépôts distants, les modules des dépôts locaux n'ont pas à être installés. Ils sont chargés directement depuis le répertoire indiqué dans le sources.list.
Conclusion
Ce mode de distribution des modules permet de pousser des mises à jour de modules immédiatement pour tous les utilisateurs d'une version donnée. Pour tester, il vous suffit d'installer la version git, et de lancer une update pour installer tous les modules référencés dans votre fichier ~/.weboob/backends.
La prochaine étape devrait être de sécuriser le téléchargement de ces modules, en utilisant un système basé sur GPG pour signer les tarballs.
Enfin, une annonce sera faite prochainement concernant le sponsoring de Weboob par un acteur majeur du Web.
# des peaux
Posté par CrEv (site web personnel) . Évalué à 9.
L'idée d'avoir un système de dépôt spécifique à un logiciel (qu'on rencontre de plus en plus souvent, en ajoutant le cpan, les gems, etc) n'est-il pas finalement contraire au système de dépôt des distributions linux ?
Cela ne montre-t-il finalement pas que les dépôts centralisés Linux ne sont pas assez efficaces, puissants, facilement maintenable ?
Puisque petit à petit on se met à installer pleins de logiciels (avec le système de dépôt de la distrib) et chacun vient avec son dépôt à lui.
(et sinon, pourquoi ne pas avoir fait un dépôt debian avec les maj, et le boob core l'aurait ajouté au sources ?)
(et sinon, pourquoi ne pas avoir utilisé les ppa ?)
[^] # Re: des peaux
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
La question serait plutôt : pourquoi les utiliser ? Les PPA, du point de vue de l'utilisateurs, ce sont des dépôts commes les autres avec une syntaxe bizarre, rien de plus…
[^] # Re: des peaux
Posté par CrEv (site web personnel) . Évalué à 1.
Ben non, je n'allais pas poser la question de les utiliser puisqu'ils ne les utilisent pas.
M'enfin !
[^] # Re: des peaux
Posté par CrEv (site web personnel) . Évalué à 2.
Plus sérieusement, pourquoi parler des ppa ?
Parce que c'est une solution facile (en tout cas pour ceux sous ubuntu) pour publier des versions, en utilisant des dépôts, mais sans toucher aux dépôts officiels.
Je vois ça surtout comme une facilité côté développeur, pour l'utilisateur ça ne change pas grand chose.
Mais je sais que beaucoup utilisent les PPA, d'où la question.
[^] # Re: des peaux
Posté par FabienC . Évalué à 5.
Je me demande surtout pourquoi les logiciels montent un systeme maison de depot plutot qu'un repository de paquet qu'on ajouterait simplement a yum.repo ou source.list ?
Peut être que la fragmentation des systèmes de paquet est une des raisons. Et qu'il serait temps de se pencher sur ce problème...
[^] # Re: des peaux
Posté par gnumdk (site web personnel) . Évalué à 10.
Wai, bonne idée, c'est quand que Redhat abandonne cette daube de RPM ? :)
[^] # Re: des peaux
Posté par Niniryoku . Évalué à 5.
Est-ce que quelqu'un peut enfin m'expliquer quel est le problème des RPM ? Parce que je n'en vois pas.
Le truc que je vois, c'est une grosse communauté de fanboys Debian qui font du gros FUD sur « apt-get gère les dépendances, pas rpm ». Basiquement, c'est vrai, mais ça m'énerve d'entendre cette connerie ; c'est comme si on disait « windows a une interface graphique, pas le noyau Linux ». rpm doit être comparé à dpkg, et apt-get à yum.
J'entends aussi beaucoup de conneries du genre « les rpm sont beaucoup plus dur à packager que les deb », alors que les personnes disant ça n'ont jamais essayé de packager ni pour l'un ni pour l'autre ; et que c'est de moins en moins vrai.
Sinon aussi :
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: des peaux
Posté par Sufflope (site web personnel) . Évalué à 2.
Tu mélanges plusieurs plugins, là :-)
Le module presto (installé par défaut sous Fedora depuis 2-3 ans) est celui qui permet ton point 1 (ne télécharger que le diff entre deux versions d'un paquet). À chaque fois que je vois que presto a diminué la volume à télécharger de X% (avec X généralement entre 70 et 90) j'ai un petit rictus de satisfaction.
Le module fastest-mirror cherche le miroir le plus rapide.
Je ne peux que plusser. Certes, parfois, c'est chiant d'attendre que yum mette à jour son cache. Ceci dit, il y a une option (genre --no-cache) pour lui dire de ne pas le faire. Et si je devais utiliser chaque occurence de « machin-x.y.z.deb not found » parce que j'avais oublié d'apt-get update avant d'install/upgrade pour contrer chaque argument « yum qui met à jour le cache c'est chiant », bah malgré plusieurs années de yum, il me resterait encore des cartouches.
[^] # Re: des peaux
Posté par CrEv (site web personnel) . Évalué à 2.
Tiens, moi c'est exactement le contraire. A chaque fois que je veux installer quelque chose avec yum ça merdouille et je cherche sur le net.
On me souffle dans l'oreille qu'en lisant la doc ça marche beaucoup mieux et que souvent on a plus de mal avec les systèmes qu'on ne connait pas.
Nan, ça doit pas être ça quand même...
D'ailleurs, en quoi urpm est pourri par rapport à yum ?
et sinon, urpm
spa si compliqué quand même, la recherche dans les paquets deb est, je trouve, beaucoup plus complexe et illisible.
[^] # Re: des peaux
Posté par Niniryoku . Évalué à 1. Dernière modification le 22 janvier 2012 à 15:55.
Encore une fois, je peux me tromper, je connais très mal urpm. Il y a déjà eu plusieurs débats sur urpm est énormément plus rapide pour la recherche et l'installation, … C'est possible, à vrai dire yum est extrêmement lent à mon goût.
Mais ce que j'adore, c'est aptitude de debian, je peux chercher, ajouter à l'installation, chercher un autre paquet, ajouter à ma liste d'installation, puis lancer l'installation. Le tout avec un accès rapide aux descriptions/dépendances, surtout le principe « shopping » comme font les interfaces graphique ou on sélectionne, on sélectionne et « acheter ».
Malheureusement, comme je l'ai dis, yum n'a pas ça. Donc je simule aptitude avec yum shell. Ça démarre yum en mode shell, ou tu peux lui enchainer des commandes du type :
Je ne crois pas qu'urpm ai une fonctionnalité de ce genre. De plus, yum fourni plein de fonctionnalités que (peut être n'ai-je juste pas trouvé) je n'ai jamais vu dans urpm (entre autre me viennent à l'esprit) :
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: des peaux
Posté par CrEv (site web personnel) . Évalué à 2.
Mouai... donc ne pas avoir un shell ça fait de urpm* un "urpmi/e est incompréhensible et pourri par rapport à yum"
Et be...
Par contre, comme tu le dis, yum est insupportablement lent. Je ne comprend même pas comment ils ont fait.
Oui, je crois bien
Mine de rien, pour trouve tout ça j'ai juste rentré urpmq dans Google mais un
man urpmqte sortira tout ce dont tu as besoin.[^] # Re: des peaux
Posté par zebra3 . Évalué à 3. Dernière modification le 23 janvier 2012 à 12:27.
Je suis Debianneux, et j'ai eu l'occasion de générer des packages dans les deux formats. À mon avis, il est plus facile de générer des paquets propres en RPM, mais il est plus simple d'en générer des simples en Deb.
Je m'explique : il existe checkinstall sous Debian qui à partir d'un simple « ./configure, make, make install » est capable de générer en une commande minimale un paquet deb, mais sans fonctions avancées comme la gestion des dépendances ou la séparation data/lib/exécutables.
A contrario, dès qu'il s'agit de faire un « vrai » paquet destiné à être déployé, effectivement je trouve plus simple d'écrire un fichier SPEC qu'une arborescence de fichiers pour Debian.
C'est pas une preuve de meilleure qualité, c'est juste qu'il fallait en choisir un pour unifier, et RHEL est la distro la plus présente en entreprise.
Si, tout de même. Deb gère les paquets recommandés, suggérés, et surtout les paquets installés automatiquement (qui permet de supprimer les bibliothèques installées avec un logiciel si elles ont été installées par dépendances).
Mais globalement, ils sont équivalents.
Il y avait aussi apt-torrent que j'avais essayé rapidement, mais je ne suis pas allé plus loin.
Je crois qu'apt a un équivalent, mais faut que je vérifie.
Mais il ne le fait plus systématiquement aujourd'hui, seulement quand il la considère obsolète (ie plus vieille de x jours). Tu peux aussi faire comme « apt-get update » avec « yum makecache ».
Là, je ne suis pas du tout d'accord : avec apt tu peux très facilement recompiler des paquets deb depuis les sources, je l'ai fait récemment (mavie : pour recompiler Vinagre après l'avoir modifié).
Pour le noyau, man make-kpkg.
Quant à RPM il me semble que c'est assez simple aussi, il suffit du fichier SPEC qui a servi à la création du paquet.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: des peaux
Posté par reno . Évalué à 2.
La même année que les distrib Linux remportent le desktop.
[^] # Re: des peaux
Posté par Juke (site web personnel) . Évalué à 0.
Je me demande surtout pourquoi les logiciels montent un systeme maison de depot plutot qu'un repository de paquet qu'on ajouterait simplement a yum.repo ou source.list ?
[^] # fatigue
Posté par Juke (site web personnel) . Évalué à 2.
y'a deja des depot de paquet qu'on ajoute simplement ici :
http://debian.weboob.org/
[^] # Re: des peaux
Posté par moules . Évalué à 3.
Ce n'est pas que c'est contraire aux dépôts des distributions Linux.
Le problème typiquement, c'est que si Weboob se retrouve dans Debian Stable, il n'y aura pas de mise à jour des paquets dans le cas où un backend est cassé.
Avoir un dépôt Debian propre, c'est ce qu'on faisait jusqu'à maintenant, mais d'une part tout le monde n'utilise pas Debian, d'autre part la mise à jour des paquets Debian c'est bien plus chiant qu'avec le système rajouté à Weboob, qui en plus fonctionne sur tous les OS.
Ça ne remet pas en cause les dépôts des distributions, le core de Weboob et les applications ont vocation à y être packagées et à rester stables. Il faut voir par contre les modules comme des data qui peuvent évoluer.
[^] # Re: des peaux
Posté par chimrod (site web personnel) . Évalué à 3.
Debian volatile n'est pas fait pour ça ?Ah non je vois que ça n'existe plus, quelqu'un sait par quoi ça a été remplacé ? Le principe ma paraît correspondre au besoin…
[^] # Re: des peaux
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
…remplacé par 'squeeze-updates' comme expliqué sur le premier lien de la page debian.org/volatile.
deb http://ftp.debian.org/debian squeeze-updates maince commentaire est sous licence cc by 4 et précédentes
[^] # Re: des peaux
Posté par zebra3 . Évalué à 2.
En suivant le lien donné sur la page d'accueil, on tombe sur ce message qui explique qu'à partir de squeeze c'est intégré au dépôt stable, ici squeeze-updates.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: des peaux
Posté par hercule_savinien . Évalué à 5.
Je ne pense pas non.
Autant je suis d'accord sur le fait que tout doit (devrait) passer par un (ou plusieurs) repo(s) de la distrib, autant ici, ça ne me choque pas.
Je m'explique.
Dans le cas de Firefox, par exemple, ça me parait complètement injustifié. Les logiciels qui se mettent à jour tout seul, c'est bien pour les Windowsiens et leur OS du 20e siècle. Mais dans le monde du libre, on a des gestionnaires de packets très très puissants et très performants.
D'ailleurs iceweasel ne se met pas à jour tout seul.
Pour autant, ça ne veut pas dire qu'il faut packager toutes les extensions de Firefox. On peut les télécharger et les mettre à jour depuis le web.
Tu donnes aussi l'exemple de cpan. Est ce que tu sais combien il y a de modules dans cpan ? Tu t'imagines faire un paquet pour chaque ? Debian aurait 4 fois plus de paquets que maintenant. Si on devait faire pareil avec cpan, les gems, pypy, les modules firefox, chromium, les backends tucan ou weboob etc. ça finirait par devenir gigantesque. Puis il faut trouver des mainteneurs pour faire tout ce travail.
Et on ne parle que de Debian. Si on multiplie ça par le nombre distributions non confidentielles, ça donne le vertige.
Pour autant, ça n'est pas incompatible. Les modules Perl les plus populaires (parfois même nécessaire pour la base du système) sont packagés, certains extensions Firefox également (même si je n'en saisis pas bien l'utilité du coup). Les deux peuvent cohabiter.
Revenons à Weboob.
Le principe du gestionnaire de paquets, c'est de gérer les dépendances. Le logiciel (le core) peut être packagé sans problème. Reste à s'assurer que les backends n'introduisent pas de nouvelles dépendances (sans mise à jour du logiciel s'entend).
Et, en pratique, tout le monde bénéficiera d'une mise à jour plus rapide, indépendante des distributions. Prenons un exemple récent : France Télévision a mis à jour son site. Ils ont viré silvershit. Ce qui est une bonne chose. Mais ça a cassé tous les logiciels basés dessus, dont Weboob.
Maintenant avec ce type de gestion, les utilisateurs peuvent avoir la mise à jour dès que le changement est releasé. Avec une procédure en mode paquet, il faut régénérer un paquet pour chaque distrib. Et si on utilise testing, il faudra attendre 10 jours pour que ça refonctionne (entre temps, peut être qu'un autre backend aura cassé. Peut être même que FT aura encore changé le site et cassé le backend). Quant aux utilisateurs de stable, il devront attendre des mois et des mois.
Si j'utilise un serveur qui fait du traitement audio/vidéo et qui a besoin de videoob, ça me ferait chier de me priver de toutes les fonctionnalités de weboob pendant des mois.
Déjà la multiplication des dépots est nuisible. Si à chaque fois que je met à jour ma distrib, je dois faire des requêtes sur des dizanes de serveurs, ça va me gonfler de perdre mon temps.
Pour moi une Debian ne doit avoir que des dépôts officiels et uniquement exceptionnellement, quand il n'y a pas d'autres solution, des dépôts externes.
Ensuite je pense que ça serait mal vécu par les utilisateurs de changer leur sources.list sans leur autorisation. C'est un peu intrusif quand même.
Le FN est un parti d'extrême droite
[^] # Re: des peaux
Posté par lathan . Évalué à 3.
Pourquoi pas un outil ou une librairie, multi-plateforme et fonctionnant en espace utilisateur, permettant à un logiciel de gérer un dépôt pour ses extensions/backend ?
Il s'agirait toujours d'éviter le système de paquet des distributions, mais sous forme de librairie, histoire d'éviter que chaque projet crée son système de dépôt maison, plus ou moins bien conçu, et venant alourdir le logiciel.
Connaissez vous un tel outil ?
Une recherche rapide n'a pas donné de résultats satisfaisants.
[^] # Re: des peaux
Posté par daeldir . Évalué à 1.
Il existe Zero Install qui est, je trouve, un projet intéressant. En gros (si mes souvenirs sont bon, ça fait un bail que je me suis pas mis à jour), chaque logiciel est installé par l'utilisateur, et peut vérifier sur un dépôt spécifique au logiciel s'il faut être mis à jour (un peu comme font Firefox, Chrome, Java… sur Windows). C'est donc un gestionnaire de paquet décentralisé. Il est aussi possible pour l'administrateur système de configurer Zero Install pour partager les logiciels installés par les utilisateurs. Si un utilisateur veut utiliser un logiciel, le système vérifie si un autre utilisateur ne l'a pas déjà installé. Il vérifie aussi que c'est la bonne version (donc, si un utilisateur met à jour le logiciel, l'autre restera s'il le veut sur l'ancienne version). Bref, plutôt que d'installer cinq fois les mêmes fichiers, le système les met à disposition de tout les utilisateurs.
http://0install.net/
J'avais essayé il y a longtemps. Le problème d'un tel système vient de sa popularité. Si personne ne l'utilise, on ne peut pas aller bien loin… Il faudra que je me repenche dessus, pour l'instant, je fais partie de ces personnes qui ne contribuent pas à sa popularité (Archlinux est pas très sympa avec ce type de projets, vu qu'on est vachement à jour, et que si on ajoute AUR en plus, on a vachement de paquets…)
[^] # Re: des peaux
Posté par moules . Évalué à 2.
Là il n'est pas question d'avoir un système pour que Weboob se mette à jour tout seul, mais pour installer et mettre à jour des modules, à l'instar des extensions Firefox.
L'idée est de continuer à garder le core et les applications gérés par le système de packages de son OS.
[^] # Re: des peaux
Posté par daeldir . Évalué à 1.
En effet, je suis un peu hors-sujet. Je répondais à cette phrase :
Mais en relisant le paragraphe qui la précède, je me rend compte que je me suis non seulement éloigné du sujet de la dépêche, mais que mon commentaire n'est pas pertinent même dans le contexte auquel je répond. Ça m'apprendra à mieux réfléchir (et ici, pas de pirouette possible du genre « oui mais Zero Install peut aussi répondre à cette problématique », ce n'est pas le cas (en tout cas, pas évidemment ni volontairement)).
Certains paquets de ces dépôts alternatifs pourraient être installés par Zero Install (comme Ruby On Rails que l'on trouve dans les Gems, et en règle générale, tout les modules qui sont aussi un logiciel), mais ces paquets sont justement ceux qui sont intégrés dans les paquets de la distribution (et c'est normal, l'objectif de Zero Install et du gestionnaire de paquetage de la distribution étant très proches, et différent de la gestion de modules).
En tout cas, je trouve que cette idée de bibliothèque commune est une très bonne idée, et j'espère qu'elle sera lue par des personnes impliquées dans le développement des différentes solutions existantes, pour engager un dialogue et proposer des solutions pertinentes à ce type de problème.
En tant qu'utilisateur, je n'aime pas beaucoup utiliser autre chose que mon gestionnaire de paquets, et j'aime encore moins avoir cinquante gestionnaires différents. Si on pouvait n'en avoir que deux, voire si la solution proposée pouvait à terme être intégrée au système de paquets utilisé par chaque distribution (par exemple, le gestionnaire de paquets utiliserait la bibliothèque proposée, et ferait une intégration automatique au système, permettant une désinstallation à partir du gestionnaire de paquets – avec gestion des dépendances), ce serait vraiment agréable.
[^] # Re: des peaux
Posté par patrick_g (site web personnel) . Évalué à 2.
Putain dire que c'est avec mon argent qu'ils ont déployé cette merde et que c'est aussi avec mon argent qu'ils l'ont remplacé par un autre truc.
J'espère que le mec qui avait décidé d'utiliser Silverlight a été pendu par les co**lles !
[^] # Re: des peaux
Posté par sifu . Évalué à 1.
Je crois avec vu passé des outils qui permettait de transformer un egg Python ou encore un gem Ruby en paquet Debian ou RPM.
Je pense que c'est un besoin d'admin (je dis cela je suis plutôt développeur à la base). Utiliser les outils de ma distribution et c'est tout !
Là, pour avoir croisé quelqu'un qui en avait le besoin, c'est clairement pour pouvoir fournir un ensemble d'extensions aux utilisateurs d'une machine (toujours en utilisant que les outils de sa distribution).
L'idéal c'est d'avoir la possibilité d'avoir un système mixte.
[^] # Re: des peaux
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Je rêve qu'un jour les gestionnaires de paquets ait une interface commune interrogeable par des applications externes (weboob, firefox, digikam,...) qui auraient la possibilité d'installer des sous-paquets (thêmes, add-ons, modules,...).
Pour la sécurité, on peu imaginer que les paquets de ces applications ont des attributs spécifiant qu'ils peuvent gérer des paquets d'un type particulier (firefox-module, firefox-theme, weboob-addon,...) et qu'est spécifié pour chacun de ces types où doivent s'installer ces paquets sur le système (/usr/share/firefox/themes/...,...) si on a donné à l'utilisateur le droit d'installer ce type de paquet de façon globale, et où il doit s'installer dans $HOME (~/.local/firefox/themes/...) si l'utilisateur a un droit d'installation sur son profile. Dans ce dernier cas, le paquet apparaitra dans la base des données paquet sous la forme paquet[user]. Par exemple : firefox-addon-greasefire[shift]. Par défaut un utilisateur n'aura pas pas le droit d'installation et dans ce cas si l'application a un moyen plus archaïque d'installer un outil elle peut le proposer.
Les installations des sous-paquets seraient sandboxée (ou chrootée) pour éviter tout problème.
Franchement ça serait le pied !
Et d'ailleurs on pourrait ne pas limiter cela à des sous-paquets mais à des types plus globaux comme web-browser, java-ide,... et on pourrait autoriser un utilisateur à installer ce genre de paquet sur son profil. Comme-ça on pourrait avoir firefox 8.1 sur le systême et firefox[shift] 9.0 sur son propre profil (dans ~/.local/bin ou un truc du genre à ajouter dans le path).
Je rêve ?
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: des peaux
Posté par moules . Évalué à 1.
C'est bien beau, mais d'un point de vue développeur, ça nécessite donc de savoir interagir avec les gestionnaires de paquets de toutes les distributions. Et ne pas proposer de gestion des mises à jour des modules pour les OS qui n'en proposent pas.
En plus de ça, il faudrait à chaque fois refaire un package des modules à mettre à jour pour toutes ces distributions, ce qui est également fastidieux.
Donc non, honnêtement, tel que ça a été mis en place dans Weboob, c'est beaucoup plus simple pour les développeurs du projet, et c'est également un gain pour l'utilisateur (c'est quasiment transparent).
[^] # Re: des peaux
Posté par Sufflope (site web personnel) . Évalué à 1.
Fais gaffe, tu vas finir en fan de SELinux (à propos duquel je ne comprends pas les critiques, maintenant que j'ai passé 1h à comprendre le principe global (comme quoi 1h c'est trop demander aux adminsys en herbe)).
[^] # Re: des peaux
Posté par zebra3 . Évalué à 3.
Je te laisse découvrir PackageKit. Il fournit des interfaces communes au dessus de nombreux gestionnaires de paquets (au moins Yum, Apt et celui de Suse, me souviens plus du nom).
Dans les outils qui s'en servent, tu as déjà Gstreamer pour des codecs manquants, le module de gestion des polices sous GNOME, Nautilus pour installer une appli pour ouvrir un fichier dont il ne connait pas le type, ou bash lorsque tu lances une commande pas installée.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: des peaux
Posté par Infernal Quack (site web personnel) . Évalué à 2.
Linuce bientôt prêt pour le destop \o/
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: des peaux
Posté par rakoo (site web personnel) . Évalué à 1.
Je pense à un développeur qui veut distribuer son application. S'il veut toucher le plus de monde, il devra packager son appli dans chaque format de paquet qui existe : deb, rpm, ports divers et variés ...
Et ceux qui n'ont pas de gestionnaire de paquets ? Et ceux qui ont un nouveau gestionnaire de paquets qui va révolutionner le monde ?
Du coup ya deux solutions pour distribuer le plus largement un logiciel :
La première solution est peu envisageable pour la plupart du monde... d'où la deuxième.
# XDG Base Directory Specification
Posté par lathan . Évalué à 10.
Il serait intéressant qu'à l'occasion de ces modifications, weboob adopte la XDG Base Directory Specification concernant les répertoires créés par les application dans le dossier utilisateur.
Pour rappel, il s'agit d'une convention visant à placer les configurations, données et caches à des endroit pré-définits ($HOME/.config, $HOME/.local/share, $HOME/.cache).
Actuellement, beaucoup d'applications créent leur répertoire à la racine du $HOME, qui mélange configurations, données et cache. Avec ces modifications apportée à weboob, c'est plus ou moins de données pour les modules qui viendraient se mélanger au $HOME/.weboob.
[^] # Re: XDG Base Directory Specification
Posté par Grunt . Évalué à 10.
Ça aurait mérité de se retrouver en tête de journal, ça. Parce que c'est franchement pénible les applications qui vont étaler leur .truc dans le $HOME.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: XDG Base Directory Specification
Posté par moules . Évalué à 8.
3/4 des applications le font. Mais c'est une suggestion qu'on va effectivement tenter de prendre en compte.
[^] # Re: XDG Base Directory Specification
Posté par Grunt . Évalué à 4.
Ça en laisse beaucoup qui ne le font pas:
182
À vue d'oeil, y'a plus de la moitié de ces .trucs qui sont causés par une application (et pas par ma faute). .gajim, .vlc, .mozilla, .gnash, .wine, .xmoto, .mplayer, et j'en passe. Et puis .X ... ah non, c'est moi ça.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: XDG Base Directory Specification
Posté par moules . Évalué à 4. Dernière modification le 20 janvier 2012 à 16:47.
C'est pas très discret .X pour ton pr0n téléchargé avec Videoob !
Et je voulais dire 3/4 des applications qui ne respectent pas les specifications XDG.
[^] # Re: XDG Base Directory Specification
Posté par lathan . Évalué à 0.
De mon coté, la proportion est loin des 3/4.
ls -a | grep "^." | wc -l
177
ls -a .config .local/share .cache | sort -u | wc -l
127
Cependant, merci moules au moins pour accueillir la suggestion, j'espère que weboob rejoindra bientôt le club !
# Question de troll :]
Posté par Grunt . Évalué à 0.
Pourquoi le choix du protocole HTTP pour récupérer des fichiers ? Vu qu'il ne s'agit pas d'une page Web, FTP n'aurait pas été plus pertinent ? Moi qui croyait que Weboob servait justement à lutter contre cette "webbisation" des Internetz..
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Question de troll :]
Posté par Buf (Mastodon) . Évalué à 9.
FTP est un protocole obsolète qui mérite d'être enterré définitivement.
Même si je suis assez d'accord pour dire que le HTTP est aujourd'hui utilisé pour un peu tout et n'importe quoi, il ne faut pas tomber dans l'excès inverse non plus. Pour télécharger un fichier depuis Internet, HTTP est parfaitement adapté.
[^] # Re: Question de troll :]
Posté par Anonyme . Évalué à 0.
Tu proposes quoi ? Tout faire passer au dessus de HTTP ? Tout faire passer au dessus de SSH (pas mieux que HTTP) ?
Un fichiers : oui ; des fichiers : non !
[^] # Re: Question de troll :]
Posté par Buf (Mastodon) . Évalué à 1.
C'est quoi le problème de tout faire passer par HTTP ? Qu'il y ait 1 fichier ou plusieurs dizaines, HTTP me semble quand même être le protocole le plus adapté (en tout cas pour une utilisation sur Internet, sur un réseau interne, un partage NFS ou autre serait plus efficace)
[^] # Re: Question de troll :]
Posté par Anonyme . Évalué à 2.
Je retourne la question puisque, à la base, c’est toi qui lance une pique contre FTP : c’est quoi le problème avec FTP ?
Non, plus il y a de fichier, plus l’overhead de HTTP est grand.
[^] # Re: Question de troll :]
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Ça utilise plusieurs ports, donc ça passe mal les pare-feux et les routeurs NAT. Ça n'est pas sécurisé.
[^] # Re: Question de troll :]
Posté par Anonyme . Évalué à -1.
Dépend qui ouvre la connexion pour les données. Mais j’avoue que c’est un bon argument.
Pas sécurisé ? Chez moi, vsFTPd utilise les comptes UNIX comme toutes les autres applications.
[^] # Re: Question de troll :]
Posté par zebra3 . Évalué à 2.
Quand il dit « pas sécurisé », je pense qu'il parle du protocole qui n'est pas chiffré.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Question de troll :]
Posté par Buf (Mastodon) . Évalué à 2. Dernière modification le 20 janvier 2012 à 17:49.
On a besoin d'argumenter un vendredi ? C'est nouveau ?
Le problème avec FTP, c'est qu'il y a 2 connexions ouvertes, une pour les commandes et une pour les données. La connexion de données pose problème au niveau des firewalls et des systèmes de translation d'adresse. Rien d'insurmontable, mais c'est du boulot en plus par rapport à HTTP qui nécessite juste de pouvoir ouvrir une connexion TCP entre le client et le serveur. Ça a aussi un cout niveau trafic réseau et ça ajoute une latence supplémentaire.
Ça suffit ou il faut que je continue en parlant de sécurité ?
On parle de quelques dizaines d'octets par fichier, c'est pas une grosse affaire. Et au passage, l'overhead du FTP est bien plus grand, parce que la connexion de données doit être réouverte pour chaque fichier (un handshake TCP par fichier, c'est considérable si on a beaucoup de petits fichiers)
[^] # Re: Question de troll :]
Posté par neil . Évalué à 1.
L'établissement de session est toujours plus long chez moi quand je dois récupérer les paquets des mises à jour de ma distribution préférée. C'est peut-être un problème avec les miroirs qui sont mal configurés, mais je préfère toujours avoir des miroirs HTTP, c'est au final beaucoup plus rapide.
[^] # Re: Question de troll :]
Posté par rakoo (site web personnel) . Évalué à 0.
Et pourquoi ne pas utiliser rsync ?
Comme ça on peut même profiter directement de sa spécificité : le téléchargement du diff si possible.
Par contre, je n'ai pas réussi à voir si rsync avait un overhead qui le mettrait trop vite de côté... et je n'ai pas (encore?) fouillé le code ni la doc.
# Avertissement des mises à jour manuel ?
Posté par Philippe F (site web personnel) . Évalué à 2.
Ce qui me surprend, c'est que tu ne présupposes pas que c'est aussi le boulot de weboob de vérifier si une version plus récente du module qu'il utilise n'est pas disponible.
Weboob étant plutôt en ligne de commande, c'est peut-être pas approprié pour tous les appels, mais ça me parait quand même approprié:
- pour les applications construites au dessus de weboob (applications graphiques)
- en cas d'erreur renvoyée
[^] # Re: Avertissement desmises àjour manuel ?
Posté par moules . Évalué à 2.
Actuellement, pour vérifier et installer les mises à jour, tu as la commande weboob-config update pour ça.
Maintenant, il est prévu également de faire en sorte que lorsqu'un module plante, il tente de vérifier si une nouvelle version n'est pas disponible et si oui l'installe.
Et c'est vrai qu'on pourrait aussi faire la vérification au lancement des applications graphiques.
# Tétracapilloctemie
Posté par Enjolras . Évalué à 3.
Bah si on connait tous, pourquoi tu nous expliques ? :Þ
Ok je sors.
[^] # Re: Tétracapilloctemie
Posté par passant·e . Évalué à 4.
et ne reviens pas!
;-)
Je trolle dès quand ça parle business, sécurité et sciences sociales
# gcstar
Posté par BAud (site web personnel) . Évalué à 2.
tiens, parler ci-dessus du cpan, des gems, des greffons firefox, ça m'a rappelé gcstar (un gestionnaire de collections genre livres, BD, DVD...) qui a aussi son propre système de mises-à-jour :
http://wiki.gcstar.org/en/update (oui, une commande à lancer en root)
pour autant, les greffons dupliqués, tripliqués, sur un système par nature multi-utilisateur...
peut-être un rpm-cpan, apt-cpan, yaourt-cpan, urpmi-cpan... et tous les modules afférents pour gérer la mise à jour (quand il n'y a pas trop de dépendances...) pour chaque type de paquets et chaque type de greffons ? (histoire d'avoir un exemple plus générique que le cpan qui pourrait déjà s'appliquer aux gems et autres dépôts ?)
ceci est un complément (gcstar) à http://linuxfr.org/nodes/89104/comments/1312302 pour illustrer qu'il n'y a pas que pypy, firefox, chromium... sans compter les déclinaisons de adblock :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.