Salut journal,
On parle assez souvent ici des packages managers (ou gestionnaires de paquets), pour la bien simple raison que c'est une partie centrale de l'OS, et qu'il est différent suivant la distribution utilisée. Les trolls s'en donne donc à coeur joie pour le plus grand plaisir des moules linusfriesques.
Cependant, on parle de quelques nouveautés, on parle des limites ou des problèmes rencontrés, on apt get à tout va pour descendre RPM ou vis-versa, on obtient parfois quelques petites infos intéressantes, mais on a jamais une vue globale de ce qui se passe dans le monde des packages managers.
C'est pourquoi je me suis mis en quête de m'informer par-ci par-là, d'appronfondir quelques sujets qui ont alléché mon navigateur oueb. Et c'est pourquoi, journal, je t'en fais profiter, en espérant en apprendre un peu plus de la part des lecteurs DLFP, qui me corrigeront sans doute, qui donneront quelques infos sur comment ça marche sur leur distrib préférée ou comment ça devrait marcher selon eux, et que trolleront à coeur joie pour le plus grand plaisir des moules.
J'aborderais donc toutes une panoplies de sujets, tous liés plus ou moins au package management, si hype dans le monde unix. J'aborderais quelques situations pratiques et nouveaux projets rencontrés via la distribution que j'utilise le plus, openSUSE, distribution relativement peu utilisé dans le monde francophone pour une foule de raison (concurrence historique de Mandrake, accord MS Novell, succès d'Ubuntu, souvenirs d'Alsace et Lorraine, ..). Cette distribution est néanmoins assez populaire en Europe du Nord, un peu de l'Est, en Italie, .. et en Allemagne, bien sûr (comme ça vous êtes prévenus :) )
Voici un rapide aperçu du contenu :
- évolution du package management
- création de paquets
- gestion des mirroirs
- unification des systèmes
Dans un autre journal, je me pencherai sur les algorithmes de résolution de dépendances. Cette partie étant relativement longue et très intéressante, j'en dédierai un journal complet.
Evolution du package management (ou le rpmdeb sapien sapien)
---------------------------------------------
Le package management sous Linux semble avoir évolué passablement au cours du temps, connaissant différentes évolutions que l'on peut qualifier de "générations"[1] :
Génération 0 - Pas de package management du tout. L'utilisateur place les fichiers individuels, là où il faut sur son système pour que ça marche.
Génération 1 - Les différents programmes sont empaquetés pour faciliter l'installation sur le système cible. L'utilisateur n'a qu'à extraire ou exécuter le paquet, mais il n'y a pas de vérification des dépendances.
S'il manque une librairie requise par le programme, il ne fonctionnera pas correctement. Exemples : La plupart des installateurs windows, de simples fichiers zip, les paquets slackware.
Génération 2 - Construite sur la génération 1, en ajoutant le support des dépendances/pré-requis. L'utilisateur connait ainsi ce qu'il doit installer avant de pouvoir installer son programme favori. Exemples : fichiers MSI, dpkg, rpm.
Génération 3 - Construite sur la génération 2, en ajoutant la résolution automatique des dépendances, à partir d'une sources de logiciels. Tous les paquets susceptibles d'être nécessaire à un programme sont directement disponibles. Exemple : apt, up2date, redcarpet, yum, urpmi, yast.
Cette génération 3 existe depuis un certains temps, et est largement utilisée dans presque toutes les distributions. Peut être est ce que le summum du package management est atteint... Peut être pas.
Cette 3e génération n'est pas sans défauts :
- Les "bonnes" sources du package manager doivent être configurés, parce qu'elles ne sont pas toujours activées par défaut, pour des raisons légales, à cause de la politique de la distribution, ou parce que le dernier logiciel top-moumoutte n'est pas dans les dépots officiels, mais directement sur le créateur du le-dit logiciel top-moumoutte. L'utilisateur devra donc chercher l'URL du dépot, trouver le fichier ou le programme dans son centre de contrôle pour ajouter ce dépot, puis enfin, pouvoir installer son logiciel. Beaucoup de chose pour un simple logiciel ? Pas pour les geeks de DLFP. Enfin, peut que si.
- L'utilisateur débutant doit apprendre à manier un front end pour son package manager, Le design de ceux-ci varie grandement, mais le premier réflexe de l'utilisateur windowsien reste sans appel : Il veut double clicker sur son fichier d'installation, et clicker sur "Suivant".
> One-Click-Install (OCI)
openSUSE (je vous avais prévenu :) ) a introduis la technologie "One-Click-Install" dans le courant 2007, rétroactivement pour la version 10.2 (sortie en décembre 06), et de base dans la dernière version 10.3 (octobre 07).
Un simple clic sur un lien web, et le package manager se lance et permet, après le mot de passe root, de cliquer sur "suivant" d'ajouter le dépot, le rafraichir, télécharger le logiciel et ses dependances, puis l'installer. A noter que OCI est le fruit d'un programmeur indépendant, et non des ingéneiurs de SuSE/Novell.
OCI porte mal son nom... puisqu'on est loin du simple clic pour l'installation d'un logiciel (4 ou 5 mini, plus le mot de passe root). Et encore heureux. En effet, le vice de cette facilité d'ajouter des dépôts et packages est.. sa facilité, justement. Facile d'ajouter un malware verreux en modifiant un simple lien sur le wiki officiel, par exemple. Le problème de la sécurité des dépôts apparaît, ou du moins, il devient plus dangereux pour un utilisateur non expérimenté d'être la victime d'une éventuelle "attaque".
Si le problème ne s'est pas (encore) présenté, c'est sans doute grâce à plusieurs facteurs :
- Le dépot doit être validé par un clé GPG. Je doute que ce soit suffisant pour éviter qu'un débutant n'installe n'importe quoi.
- Un changement sur le wiki openSUSE ne passerait pas inaperçu, et serait corrigé de suite.
- La "websphère" de la distribution est assez limitée: très peu de dépôts sont situés en dehors du Build Service openSUSE (uniquement ceux qui ne peuvent y être pour raison légale - VideoLan, Packman, .. d'autres?), le blog des développeurs planetsuse.org. La plupart des liens OCI sont "sous contrôle".
Mais c'est insuffisant. Des solutions pour "sécuriser" le système (ou le comportement chaise/clavier, plutôt) sont étudiées. Un système de confiance donné par vote (trust rating) sera donné à chaque dépot du BuildService openSUSE. C'est un premier pas, même si je ne suis personnelement pas convaincu de l'efficacité du système.
> Mon expérience :
En quelques semaines, l'environnement openSUSE change : Les liens 1-click-install profusionnent sur le wiki, l'aide sur les canaux IRC est transformé : un simple !command et le bot IRC crache le bon lien pour installer le tout dernier compiz-fusion-gl-etreme-mod-crystal-top-moumoutte. Le package manager devient beaucoup plus transparent, plus invisible à l'utilisateur final. Les débutants sont comblés. Et les habitués aussi.
Les bénéfices, pour une distribution grand public sont conséquent et je pense que cette pratique sera étendue à la plupart des distributions.
La technologie OCI continue d'évoluer, avec des variantes en consoles, des interfaces graphiques pour créer des lien OCI, la génération automatique des ces liens à partir d'une liste prédéfinie, l'utilisation généralisé dans les moteurs de recherche de paquets openSUSE [3][4] et dans le futur Software Portail Communautaire [5].
Création de paquets (ou comment emballer le chocolat dans le papier d'alu)
--------------------------
Un autre sujet récurrent dans les journaux des moules est la création de package. En effet, s'il existe différents formats (deb, rpm, tgz, .. ), un même format est souvent incompatible entre distributions, et les paquets d'une version d'une distribution est plus ou moins incompatible avec la version suivante ou antérieure.
Cette situation conduit le créateur d'un programme, qui désire diffuser son travail, à différentes options :
- trouver et faire appel à un packager pour chacune des distributions. Avec bien sur aucune assurance sur l'efficacité et le suivi de celui-ci sur son projet et ses mises à jour.
- créer lui-même moultes versions de son programme top-moumoutte, une pour chaque distribution (du moins les principales). Outre le fait qu'il devra se familiariser avec les différentes procédures deb, rpm, archbuild, et autres, il devra tenir ces paquets à jour avec les toutes nouvelles versions de son programmes.
- ne rien faire, et laisser les sources de son programme en tar.gz sur son site oueb. Peut être pas la meilleure solution pour faire connaître son top moumoute de programme ré-vo-lu-tionaire.
> les solutions décentralisées
Une solution originale qui a émergée sont les package manager décentralisés, qui permettent de creer un seul et unique paquet qui s'installera sur chaque distribution. Un article général présentant bien le concept, écrit par l'auteur de ZeroInstall l'année passée, et avec tout plein de beau schéma est disponible ici [6].
L'article pointe du doigt les effets "pervers" du cloisonnement du système de chaque distribution, et les défis rencontrés par les packages manager décentralisés. Il est relativement technique, mais très intéressant pour qui veux comprendre le fonctionnement de klik, autopackage et autre ZeroInstall.
Concrètement, le principe utilisé est similaire à la manière windowsienne de procédé : Après l'installation d'un client, on peut télécharger des paquets indépendants (comme un exe) ou un fichier pointant vers des repo online (à la manière OCI présentée ci-dessus). On clique et le paquet s'installe (télécharge et installe les dépendances) avec ses librairies statistiquement liés dans /home. Certains vont plus loin, en utilisant les librairies dynamiques du système si elles sont détectées sur le système cible, ou essai même d'intéragir avec le package manager en place pour éviter les doublons de programmes.
Les inconvénients de cette méthode sont bien sur ces librairies statiques, à contre courant du principe meme du package management, la non utilisation de dépots centralisés si pratique, et cette impression d'installer (ou ne pas installer justement) un paquet non géré par ce bon vieux package manager. Mais force est de constater qu'il y a des progrès et que la marge de progression est grande.
> openSUSE Build Service (oBS)
L'openSUSE Build Service[7], lui, reste dans la philosophie traditionnel des systèmes centralisé. Son utilisation primaire est de fournir une grande variétés de paquets pour les distributions openSUSE, des nouvelles versions de paquets de divers projets (KDE4, ..), des paquets "third-party" et des backports pour les différentes versions stables de la distribution. Il est assez similaire au système de build public de Fedora.
L'infrastructure permet ainsi de compiler les paquets à distance, dans une machine virtuelle Xen lancé par le packager via une interface web ou un client en ligne de commande. Toute l'infrastructure du Build Service tourne sur plus d'une centaine de machines généreusement données par AMD au projet openSUSE, et le code du Build Service est disponible librement. A noter que la version de développement openSUSE est désormais construite dans le Build Server.
Là où c'est intéressant pour un packager, c'est que le Build Service permet, simplement à tout un chacun, de créer des paquets pour différentes distributions, à partir d'un unique fichier de configuration (.spec file). La gestion des doits est bien sûr gérée, de sorte que plusieurs personnes peuvent s'occuper d'un certain projet.
Le Build Service a de multiples avantages :
- Il resoud automatiquement les dépendances des paquets compilés. Ainsi, si un paquet B dépend d'un autre paquet A, le paquet B va être automatiquement recompilé si la dépendance A est modifiée et recompilée. On a ainsi l'assurance que ce paquet va bel et bien être compatible avec une certaine version d'une distribution.
- Il permet de lier des projets entre eux. Ainsi, un patch peut être avec la nouvelle version d'un autre projet. Un développeur qui créer un patch pour Amarok dans son environnement local (compte du build service) peut le tester dans un environnement différent que le sien. En liant son amarok patché au projet KDE, il a l'assurance que sa version patchée d'amarok sera recompilé lorsque le projet KDE sera recompilé.
- Il permet de compiler pour de multiple distributions, à partir d'un seul fichier de configuration (.spec). Actuellement, les distributions supportées sont SUSE Enterprise et openSUSE (10.1, 10.2, 10.3, Factory, SLE 9 et 10), Fedora (6, 7, 8) et RH Enterprise (RHE 5, Centos 5), Mandriva (2006, 2007 et 2008), Debian etch et xUbuntu (6.04, 7.04, 7.10).
- Enfin, le build service est synchronisé sur plusieurs miroirs, la disponibilité des paquets est garantie en tous temps.
Le système n'est pas parfait, parfois les paquets ne compilent pas (des outils de monitoring via l'interface sont là pour aider à déterminer ce qui ne va pas et ce qui doit être changé dans le fichier .spec du paquet), et toutes les distribtions ne sont pas prises en compte, mais c'est un premier pas vers un système de build qui n'est pas entièrement spécifique à une distribution.
Un utilisateur Fedora a testé l'infrastructure oBS l'année passée, vous pouvez lire son retour d'expérience ici [8]
> Mon expérience
Ben j'suis une daube en packaging, mais c'est pas le sujet :).L'interface est agréable et intuitive, et quelques changement sont prévu prochainement pour encore l'améliorer. Le client CLI semble efficace, mais j'ai pas vraiment poussé plus loin. A voir pour les packagers en herbe...
Quelques statistiques au passage :
A la semaine du 5 mars, le Build Service contenait 2035 (+50 par rapport à la semaine précédente) projets, 34531 (+145) packages, 4751 (+122) dépôts par 4575 (+129) utilisateurs confirmés.
Il faut bien sur modérer le nombre de paquets, puisque il y a plusieurs architectures, pour plusieurs distributions, et que parfois un seul paquet sources peut produire plusieurs paquets binaires.
Gestion des mirroirs (ou savoir qui est le plus beau)
------------------------
Il y a une chose qui m'a toujours déça lorsque j'utilisais mon package manager finement configuré : Le mirroir que j'avais entré était momentanément mort, et précisément à l'instant où j'en avais crucialement besoin :)
La parade consistait donc
- à chercher sur le wiki la liste des miroirs officiels
- à entrer auparavant plusieurs miroirs pour chaque source, fonctionnalité prise en charge par bon nombre de package managers.
Il faut donc contourner le problème d'indisponibilité momentanée, du coté client. Et pourquoi pas côté serveur ?
Voyons ce que contient les serveurs openSUSE[9] :
distribution openSUSE 10.1, 10.2, 10.3, snapshots unstable (alpha et beta)
3 architectures, les sources, les paquets debuginfos, les branches de test, les branches drpmsync, et bien sûr, les dépots du Build Service.
Combien cela répresente-il ?
- Plus de 700'000 fichiers dans la branche openSUSE :
/distribution: 289794
/update: 14896 (seulement 10.3)
/repositories: 413142
Taille totale : 864 Go (état début mars), 15'000'000 à 40'000'000 de requêtes HTTP par jour.
Une sacrée charge. Existe-t-il un serveur avec une telle capacité ?
En comparaison, un mirroir ubuntu entier (incluant ISO) pèse ~ 260Go, debian (sans ISO) pèse ~320Go (le nombre de requêtes journalière doit être bien plus élevée cependant)
Et c'est là que les mirroirs viennent à la rescousse.
Est-ce que tous les mirroirs openSUSE sont égaux ? Dans le temps pré-Novell, oui. Il n'y avait pas autant de paquets disponibles pour la distribution. Mais depuis l'ouverture de la distribution, chaque mirroir n'a pas forcément le même contenu que son voisin (limitations de capacité).
Effectivement, avec la taille nécessaire pour acceuillir le contenu total des FTPs, il n'y a _plus_ de mirroirs complets.
Certains ne mettent à disposition que la dernière release (10.3), d'autres seuelement les repos du Build Service. D'autres ne sont peut être pas encore à jour avec les tous derniers builds.
Seuls quelques fous mettre à disposition l'ensemble du contenu (800+Go), mais les dev ont déjà du mal à trouver un mirroir pour le BuildService (+200Go). Sans compter que ce contenu change très souvent, à tel point que parfois, lorsqu'une synchronisation de tous les serveurs est terminée, le contenu à déjà changé sur les serveurs principaux !
Comment donc utiliser les mirroirs, si l'état de ceux-ci changent continuellement de complet et à jour, à incomplets et pas à jour ?
> openSUSE download redirector : mod_zrkadlo
Une solution proposée est de créer de listes dynamiques du contenu de chaque mirroir. Si on ne peut pas contrôler le contenu des mirroirs, on peut en revanche les observer.
Le choix d'un miroir est avant tout déterminé par localisation de l'IP (GeoIP), puis les choix potentiels sont analysés : le redirecteur est lié à une base de donnée SQL qui connait le contenu exact de chacun des mirroirs. Cette base de donnée est actualisée périodiquement par un scanner qui analyse tous les miroirs, et de plus un programme "ping" contrôle la réactivité du mirroir par intermittence, et peut ainsi désactiver ou mettre en pause la redirection vers un certain mirroir. Tout ca est implémenté de façon générique dans un module apache écrit en C, mod_zrkadlo[11]. Pour la petite histoire, le développeur de ce module a assister à un concert en Slovaquie d'un groupe nommé "Za Zrkadlom - behind the mirror", zrkadlo signifiant "mirroir", et il lui fallait un nom :)
Le désavantage de ce système de gestion de miroir, est qu'il doit être d'une fiabilité aboslue. Une panne du redirecteur, et c'est tout le système qui chute... Le recours manuel à la liste officielle des miroirs étant l'unique solution si le client n'implémente pas une liste de miroirs en cache (le client natif zypp n'inclut pas encore ça, mais c'est prévu). Sinon, outre la souplesse que ce système procure, il est possible de compter les téléchargements d'une manière relativement fiable.
Notons que des systèmes à peu près similaires existent déjà, et ont servi de modèles pour ce module : sourceforge, boucer (mozilla) qui est implémentée en php, Fedora MirrorManager qui est très similaire avec une approche un peu différente (évolution d'une liste statique à une liste prégénérée), qui est implémentée avec moins de granularité mais qui dispose d'une liste de secours en cas de problème, et mod_offload (icculus.org)
> Mon expérience
Ca marche au poil, même les jours de release on tombe sur un serveur rapide. Par contre, quand le RAID qui supporte le redirecteur lâche (comme à la mi-février), c'est 24h sans possibilité de faire quoique ce soit, à part utiliser manuellement un miroir qui va bien.. Pas top pour les débutants, espérons que le fallback système soit implémenté rapidement.
Unification des packages management (ou comment on les clonera tous)
-----------------------------------
Je suis tombé l'autre jour sur un blog qui m'a fait un peu sourire[12].
L'auteur proposais d'unifier les meta-packages manager (apt, yum, urpmi) au travers d'un nouveau système UPS, Unified Package Manager.
Pour unifier .deb et .rpm, l'auteur propose une nouvelle spécification UPS (Unified Package System) qui conviendrait à tous le monde, et de creer UPS, Unified Package Format.
Si l'attention est louable et que l'auteur propose une démarche pour développer ce nouveau format, je doute un peu du succès que pourrait avoir l'abandon de deb et rpm tant ils sont populaires. Cependant, si l'unification des formats ne semble pas réaliste, celui de l'unification des front-end est une voie à explorer.
> Smart PM
Smart[13] est un premier essai, développé par l'ex-mainteneur d'apt4rpm chez Connectiva (et qui travaille chez Ubuntu actuellement je crois). Smart peut être utilisé sur n'importe quel système, puisqu'il reconnait les différents dépots RPM (apt4rpm, rpm-md, red carpet, urpm, ..), deb, slackware. Si son algorithme semble un peu plus évolué et puissant que ce qui existe actuellement (je reviendrai la dessus dans un prochain journal), je n'ai pas l'impression qu'il est arrivé à détroner le package manager d'une distribution ou d'une autre, peut être à cause de son efficacité un peu trop "aggressive" (je me rappelle avoir eu pas mal de souci lors d'un dist-upgrade).
> PackageKit
Au contraire de Smart, PackageKit[14] n'est qu'une interface qui n'essai pas de réinventer la roue. Son but premier est d'unifier toutes les interfaces graphiques utilisées dans les différentes distributions, et d'utiliser les dernieres technologies pour que le processus "suck less".
Ce logiciel met a disposition une série d'abstraction D-BUS qui repose sur les différentes technologies des meta-packagers existants, et utilise ceux-ci pour la résolution des dépendances. Avec PoliceKit, il permet à l'utilisateur d'une session de manager ses paquets de façon sécurisé, grâce à une API cross distribution et cross-architecture. L'etat actuel de l'implémentation des différents backend est visible dans ce tableau[15]
PackageKit n'est pas sponsorisé, mais le projet semble intéresser Red Hat, openSUSE et surement quelques autres. Un avenir prometteur ?
Ainsi journal, je te laisse méditer sur ce (trop) long journal, et te donne rendez vous pour le prochain, qui traitera de façon pas trop superficielle les algorithmes de résolution des dépendances, les limites actuelles et peut être quelques solutions prometteuses.
Sources et info :
---------------------
[1] http://blogs.warwick.ac.uk/bweber/entry/next_generation_pack(...)
[2] http://en.opensuse.org/Meta_Packages
[3] http://software.opensuse.org/search?baseproject=openSUSE:10.(...)
[4] http://packages.opensuse-community.org/
[5] http://en.opensuse.org/Software_Portal
[6] http://osnews.com/story/16956/Decentralised-Installation-Sys(...)
[7] http://en.opensuse.org/Build_Service
[8] http://liquidat.wordpress.com/2007/07/06/using-the-opensuse-(...)
[9] http://www.poeml.de/~poeml/talks/redirector/
[10] http://en.opensuse.org/Build_Service/Redirector
[11] http://www.zrkadlo.org
[12] http://computerstuff.jdarx.info/content/unified-package-mana(...)
[13] http://labix.org/smart
[14] http://www.packagekit.org/
[15] http://www.packagekit.org/pk-faq.html
Journal Diverses choses sur les packages managers
9
mar.
2008
# Ce journal...
Posté par vincent_k (site web personnel) . Évalué à 10.
[^] # Re: Ce journal...
Posté par Spyhawk . Évalué à 10.
Cette petite exploration présente avant tout mon point de vue, avec un biais sur les techniques employés par la distribution que j'utilise. Je n'ai pas le recul nécessaire ou une connaissance suffisante des autres distributions, bref, pas vraiment d'objectivité. Et comme précisé dans l'entête, les lecteurs me corrigeront.
Par contre, je n'avais pas assez de XP pour le placer en journal de première page...
[^] # Re: Ce journal...
Posté par Thomas Douillard . Évalué à 7.
Bref, à mon avis tu y a passé suffisament de temps et le résultat est suffisament bien pour en faire (bien) plus qu'un journal, genre c'est publiable dans linuxmag.
Pour le reste, on peut compter sur les commentaires pour compléter, et encore c'est même pas sûr.
[^] # Re: Ce journal...
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Sinon, c'est très instructif comme journal.
[^] # Re: Ce journal...
Posté par alexissoft . Évalué à 0.
[^] # Re: Ce journal...
Posté par alexissoft . Évalué à 10.
# Gdebi
Posté par gyhelle . Évalué à 10.
[^] # Re: Gdebi
Posté par alexmic . Évalué à 1.
# openSuse vs debian
Posté par Maclag . Évalué à 7.
Un miroir Suse c'est plus de 800Go de données avec ~3.5 versions (3 Suse + exp) + Build pour plusieurs architectures.
Mais les autres distribs aussi, elles ont plusieurs architectures et plusieurs versions.
Debian (par EXEMPLE) tourne sur plus d'architectures, a 3 versions + experimental, et j'ai toujours cru que Debian avait plus de paquets que les autres.
Suse proposerait-elle tellement plus de logiciels dans ses versions officielles??
Et sinon, rien à voir, mais y'a pas un patrick_g dans ta famille?? (rapport à la qualité du journal)
[^] # Re: openSuse vs debian
Posté par Spyhawk . Évalué à 6.
Mais rien que l'arbre FTP d'une seule version openSUSE et pour une architecture doit tourner autour des 15 à 20 Go si mes souvenirs sont bons.
Le BuildService (/repositories) contient des mises à jours semi-officielles pour plein de composants (KDE3 et 4, GNOME, Xorg, drivers, etc.) mais surtout, la grosse partie du contenu est faite des builds personnels des utilisateurs (/repositories/home:). Des paquets peuvent donc y être sous différentes formes et versions (genre un blender 2.43, 2.44, avec tel ou tel patch, etc.)
En ce qui concerne le nombre de package, je sais qu'avant l'ère Novell la distribution entière tenait sur un DVD double (pour une arch). Depuis, le nombre de paquets a complètement explosé. Selon la mailing-list de septembre 07 [1], le nombre de paquets sources était de ~3500+ dans le Build service (sans compter le /repositories/home:), et ~2500+ dans le repo communautaire packman (pour ~14'000 binaires)
Sinon, je crois que Gentoo est passé devant debian depuis un moment en terme de nombre de paquets différents absolu.
Et non, il n'y a pas de patrick_g dans ma famille. La preuve est qu'il y a un gros gène de monstrueuses fautes d'ortho dans la mienne...
[1] http://lists.opensuse.org/opensuse-project/2007-09/msg00074.(...)
[^] # Re: openSuse vs debian
Posté par Jean B . Évalué à 3.
Il y a 24cds pour une testing i386.
Si on multiplie par 14 architectures fois 3 branches.
Ben ça fait 823Go (plus l'expérimental dont je n'ai aucune idée de la taille)
[^] # Re: openSuse vs debian
Posté par Oook . Évalué à 2.
Genre, (au hasard sans vérification hein ;) ) : Open Office sur arm, je pense pas que ce soit possible (ni même souhaitable...).
[^] # Re: openSuse vs debian
Posté par Jean B . Évalué à 2.
Try again?
Sans rire oui il doit bien avoir quelques paquets non dispo sur toutes les archis à commencer par les non-free.
Mais en même temps je ne cherche pas spécialement à savoir qui a la plus grosse. Je voulais juste par curiosité faire une estimation de la taille des dépôts.
Ça pourrait d'ailleurs faire un excellent troll ...
[^] # Re: openSuse vs debian
Posté par Nicolas Schoonbroodt . Évalué à 3.
[^] # Re: openSuse vs debian
Posté par Maclag . Évalué à 1.
http://www.debian.org/mirror/size (Debian 290Go)
http://wiki.mandriva.com/en/Development/Howto/Mirror (Mandriva 700Go)
http://fedoraproject.org/wiki/Infrastructure/Mirroring (Fedora 663Go -très précis!-)
http://www.netbsd.org/docs/mirror.html#ftp-diskspace (NetBSD 256Go au total)
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/hubs/mir(...) (FreeBSD environ 420Go au total)
J'en tombe des nues tellement que j'ai vécu des années convaincu que Debian était "la plus grosse" avec plein d'architectures et des milliers de contributeurs!
Comme quoi!
(bon ceci dit j'en changerai pas pour ça hein!)
Enfin, juste une question subsidiaire aux utilisateurs de fedora, suse, mandriva & co.:
Dans Debian, il y a un certain nombre de paquets communs à plusieurs archis (aucune idée du volume en en Go). C'est pareil chez vous?
[^] # Re: openSuse vs debian
Posté par imalip . Évalué à 5.
j'ai vécu des années convaincu que Debian était "la plus grosse" avec plein d'architectures et des milliers de contributeurs!Le miroir Mandriva contient toutes les releases depuis la 7.1 (ca en fait 11) avec les iso, forcement, ca monte vite.
Meme ordre d'idee pour NetBSD et FreeBSD.
Fedora contient egalement les iso, et il semblerait que les 663 Go soient en comptant toutes les releases, vu qu'ils annoncent une augmentation de 100Go par release.
Un miroir Debian contient par comparaison sarge, etch, lenny, sid et experimental, environ 2Go de donnees qui ne sont pas des paquets, et pas d'isos du tout. Et Lenny et Sid ont beaucoup de packages en commun
[^] # Re: openSuse vs debian
Posté par IsNotGood . Évalué à 3.
Non, ce n'est pas en comptant toutes les releases. Sur fr2.rpmfind.net, Fedora (rawhide + F7 + F8 + mise à jour) c'est 480 Go. Par contre fr2.rpmfind.net n'a les debuginfo que pour Rawhide. D'où probablement le fait que fr2.rpmfind.net ne fait pas 660 Go.
La GPL impose la disponibilité sur 3 ans des sources. Red Hat archive toutes les release sur un serveur (je ne sais plus où).
Serveur principale Fedora :
http://download.fedora.redhat.com/pub/fedora/linux/releases/
Il n'y a que F7 et F8 (qui sont les distributions actuellement maintenues).
[^] # Re: openSuse vs debian
Posté par IsNotGood . Évalué à 3.
C'est le cas pour la grande grande grande majorité des paquets de Fedora. Les exceptions sont rarissimes (genre IcedTea qui ne tournait pas sur ppc).
[^] # Re: openSuse vs debian
Posté par Nicolas Schoonbroodt . Évalué à 4.
Si c'est comme ça sur fédora, toutes mes excuses, mais ça ne transpirait pas de ton message.
[^] # Re: openSuse vs debian
Posté par IsNotGood . Évalué à 2.
Pour Fedora, ça utilise les caractéristiques de rpm. wesnoth-1.2.8-2.fc8.i386.rpm, wesnoth-1.2.8-2.fc8.x86_64.rpm, etc.
Spécifiquement pour wesnoth il n'y a pas de wesnoth-data (le paquet n'a pas été fait ainsi, faut pas chercher midi à 14 h dans cet exemple).
Ici encore Fedora utilise les caractéristique de rpm (le champ ARCH).
Par exemple pour le noyau :
source : (généralement le même pour tout le monde)
kernel-2.6.24.3-12.fc8.src.rpm <= le même pour tout le monde
sur dépôt i386 :
kernel-2.6.24.3-12.fc8.i586.rpm
kernel-2.6.24.3-12.fc8.i686.rpm
...
kernel-doc-2.6.24.3-12.fc8.noarch.rpm <= le même pour tout le monde (hardlink)
sur dépôt x86_64 :
kernel-2.6.24.3-12.fc8.x86_64.rpm
...
kernel-doc-2.6.24.3-12.fc8.noarch.rpm <= le même pour tout le monde (hardlink)
Il n'y a pas de distinct "data" ou "programme", mais la distinction architecture indépendant (noarch).
Ainsi yum est le même pour tout le monde (aussi bien source que programme) :
source :
yum-3.2.8-2.fc8.src.rpm
sur dépôt i386 :
yum-3.2.8-2.fc8.noarch.rpm
sur dépôt x86_64 :
yum-3.2.8-2.fc8.noarch.rpm
Ce sont bien les mêmes, le md5sum peut le confirmer.
Mais on peut avoir des trucs surprenants. Par exemple toutes les traductions OOo sont architectures dépendants... Faut voir ça comme un bug upstream.
Un parquet n'est pas construit d'un coup. Par exemple pour kernel (Linux) il est contruit avec --target noarch (ce qui va être généré sera le même pour tout le monde), puis --target i586, puis --target i686, puis --target x86_68, etc...
# Alien
Posté par Thibault (site web personnel) . Évalué à 2.
Concernant la partie "Création de paquets (ou comment emballer le chocolat dans le papier d'alu)" il y a aussi une autre solution que j'ai été ammenné à utiliser : http://kitenet.net/~joey/code/alien/
Ca permet d'une manière plus ou moins transparente d'installer des RPM sous debian par exemple mais je n'ai pas testé en profondeur.
[^] # Re: Alien
Posté par vincent_k (site web personnel) . Évalué à 2.
RedHat développe une version amélioré de tar : star et avec les en-têtes xml comme le fait mandriva sur sa spring (je ne sais pas comment font les autres), je pense, qu'on peut avoir un sytème de paquet complètement indépendant de la distribution.
Enfin pour le moment ça reste une utopie et ça me fait penser à ce qu'ont vécue les unix en leurs temps.
[^] # Re: Alien
Posté par jeffcom . Évalué à 6.
pourquoi le rpm est-il plus "standard" que le deb (pas exemple) ? parce qu'il est utilisé par "plus" de distribs ? à mon sens ce raisonnement est bancal...
[^] # Re: Alien
Posté par fusible . Évalué à 2.
[...] la LSB spécifie que les paquets (systèmes d'installation de logiciels) doivent être au format RPM [...]
Voilà, je pense que c'est pour ça.
[^] # Re: Alien
Posté par GG (site web personnel) . Évalué à 3.
[...] la LSB spécifie que les paquets...
Ce n'est pas parce qu'il y a le mot standard que c'est effectivement un standard.
LSB est une tentative de standardisation, discutable.
On pourrait dire que vu la qualité des .deb cela devrait être un bon standard, mais comme ce n'est pas l'objectif de la communauté Debian de s'octroyer des titres ronflants ou des fleurs, on reste modeste malgré les petites différences de fonctionnalités entre les paquets rpm et les paquets deb.
Un des avantages que j'aime dans les paquets debian, c'est les "suggestions".
Si on en reste dans les standards, ça rendra le LSB comme l'OS de MS, c'est à dire que tout ce qui ne sera pas standard ne sera pas géré...
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Alien
Posté par fusible . Évalué à 1.
Ce n'est pas ce que je voulais dire. Je ne fais que présumer que c'est à la LSB que pensait vincent_k dans son post plus haut. J'ai d'ailleurs mis le lien Wikipédia plutôt que le site officiel justement pour ça. Ma citation est, de plus, tirée du chapitre « critiques ». ;)
À titre personnel, je n'utilise ni .deb ni d'adamrpm et la compatibilité binaire entre distros ne m'intéresse que lorsque je veus installer la dernière version de Wesnoth chez un pote : sous Windows aucun problème, par contre s'il est sous Linux... je regrette à chaque fois qu'ils ne fournissent pas un bon vieux tar.gz compilé statiquement. :/
[^] # Re: Alien
Posté par Anonyme . Évalué à 3.
# Upak
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 1.
Upak (United Packagers) : [http://wiki.freebsd.org/Upak]
et du même auteur, Andrew Pantyukhin, une présentation plus spécialement orientée vers les systèmes BSD :
[http://people.freebsd.org/~sat/pmp/papref.pdf]
# Très intéressant, mais il manque
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 5.
Etant un utilisateur principalement de BSD, je me suis posé une question en lisant ton journal: quid des systèmes de packages non binaires ?
Je pense aux ports de FreeBSD, aux packages de NetBSD, et au machin de Gentoo. Les packages de NetBSD sont en plus portables, et utilisables sur de nombeux autres OS. Selon l'avancement du système, t'as une plus ou moins bonne gestion des dépendances, tu peux, au choix, décider de recompiler ou non tout ce qui dépend d'un paquet (très utile si la nouvelle version corrige un bug qui ne te concerne pas, ou rajoute des features dont tu n'as que faire)...
De plus, il est, je pense, difficile de corrompre un logiciel installable par ces procédés, car les ports sont gérés par des mainteners officiels, et que si c'est pas dans l'arborescence officielle, alors c'est pas bon.
En revanche, on perd ici de la rapidité d'installation, mais il y a des serveurs qui se chargent de compiler les binaires (parfois pas pour certain, et j'ai jamais su pourquoi)
Bref, je pense qu'un bon gestionnaire de package doit d'abord bien gérer les sources, pour ensuite manipuler du binaire, et ne pas accepter les logiciels non signés (ton logiciel révolutionaire attendra bien deux ou trois jours pour être vérifié par un officiel du gestionnaire de packages, non ?)
[^] # PKGSRC powaaa !
Posté par kowalsky . Évalué à 5.
( bien qu'un peu court :) ).
Moi je suis un gros mordu de pkgsrc. J'en mange tout les matins au
petit déjeuné, et même si à coté de pkgsrc, il y a pkg_add et autres,
ça, je trouve que c'est plus orienté administrateur.
pkgsrc, c'est bon pour avoir des packages avec certaines options à
la compilation ( mysql, mod_perl, apache, noyau, etc... ) mais pour
une distrib orienté utilisateur, c'est à coté de la plaque. Ou plutot,
sur le poste client, c'est à coté de la plaque, pour le service qui
gère les packages coté distrib, c'est de la bombe par contre.
Pourquoi sinon, les distribs centralisent les rpm, deb et autres sur un
serveur, et ne font pas à la pkgsrc, hébergé les paquets par le site
de l'auteur ( entre autre ) ?
pkgsrc possede deux sites ou tout les tarballs sont dispo, mais pkgsrc
par default, va chercher d'abord sur les sites des auteurs.
[^] # Re: Très intéressant, mais il manque
Posté par pyrollo (site web personnel) . Évalué à 1.
L'idée de vouloir unifier les gestionnaires de packages est louable mais plutôt que de vouloir faire tomber la frontière entre deb et rpm, il serait bien plus intéressant de faire tomber celle entre gestionnaire binaire et gestionnaire source.
Au début j'ai utilisé Mandrake mais il m'a fallu effectuer des recompilations manuelles prendre en compte certaines options dont le support n'était pas intégré dans les rpm proposés. A chaque mise à jour il faillait effectuer l'opération de nouveau.
Je me suis donc tourné vers une Gentoo dont la gestion des packages offre toute la souplesse dont on peut avoir besoin lorsque l'on s'écarte des sentiers battus. Cependant, chaque mise à jour doit surveillée et prend des plombes sur une vieille machine.
Je suis donc revenu, pour les PC bureautique à une distribution binaire.
Tout ça pour dire que mon idéal serait une distribution qui propose par défaut des packets binaires mais avec la possibilité de gérer certains packets à la façon Gentoo (à partir des sources avec des USE flags) en prenant en compte les futures mises à jour de la même façon.
[^] # Re: Très intéressant, mais il manque
Posté par Sufflope (site web personnel) . Évalué à 2.
# Installation en un clic
Posté par Jérôme Pinot (site web personnel) . Évalué à 3.
openSUSE (je vous avais prévenu :) ) a introduis la technologie "One-Click-Install" dans le courant 2007, rétroactivement pour la version 10.2 (sortie en décembre 06), et de base dans la dernière version 10.3 (octobre 07).
Ou comment faire passer Novell pour une société innovante... Ils n'ont rien introduit, ils ont copié.
Un simple clic sur un lien web, et le package manager se lance et permet, après le mot de passe root, de cliquer sur "suivant" d'ajouter le dépot, le rafraichir, télécharger le logiciel et ses dependances, puis l'installer. A noter que OCI est le fruit d'un programmeur indépendant, et non des ingéneiurs de SuSE/Novell.
Ce système est dérivé du Click'N'Run, que Linspire (anciennement Lindows) a développé et utilisé depuis bien 5 ans. À l'origine non-libre, le code a été libéré il y a 2 ans.
On peut avoir des griefs contre Linspire et sa politique du libre, il n'empêche qu'elle est la première distribution Linux à avoir introduit le concept d'installation en un clic via le web, et cela, des années avant SuSE.
[^] # Re: Installation en un clic
Posté par Temsa (site web personnel) . Évalué à 0.
[^] # Re: Installation en un clic
Posté par IsNotGood . Évalué à 4.
Faudrait pas s'extasier sur ce type de truc.
Il y a une tripotée d'année (à l'époque Fedora n'existe pas) lorsqu'on cliquait sur un rpm dans mozilla, le paquet s'installait (demande de mot de passe, résolution des dépendances, etc).
C'était simplement mozilla qui était configuré pour lancer "redhat-config-package url" lorqu'une url type rpm était demandée.
Voilà, c'était rien de plus.
[^] # Re: Installation en un clic
Posté par jeffcom . Évalué à 2.
# Re:
Posté par IsNotGood . Évalué à 3.
Je ne crois pas. Ça va surtout intéresser les kékés.
> Toute l'infrastructure du Build Service tourne sur plus d'une centaine de machines généreusement données par AMD au projet openSUSE
Et pourquoi pas des milliers !
Pour Fedora (compilation i386, x86_64, ppc et ppc64), il n'y a "que" dix machines (certaines virtuelles) :
http://koji.fedoraproject.org/koji/hosts
Et tout y est compilé, ce n'est pas que dédié "extras". La distribution y est compilé, les mises à jours, les contributions externes, rawhide, etc.
> Le Build Service a de multiples avantages :
> - Il resoud automatiquement les dépendances des paquets compilés.
Ce n'est pas un avantage, c'est une nécessité.
> Ainsi, si un paquet B dépend d'un autre paquet A, le paquet B va être automatiquement recompilé si la dépendance A est modifiée et recompilée.
"Foutaise".
Presque tous les paquets dépendent de libc ou gcc. Si libc ou gcc est changé, tu nous expliques que le build système va recompiler tous les paquets !
Et comment tu fais pour gérer les versions ? Ben oui, il va y avoir des toto-1.0-1 avec différent libc et gcc. Ça sucks.
Bref, ce truc je n'y crois pas.
> En comparaison, un mirroir ubuntu entier (incluant ISO) pèse ~ 260Go, debian (sans ISO) pèse ~320Go
Pour info :
Le mirror Fedora sur fr2.rpmfind.net (rawhide, et "seulement" F7 et F8) : 480 Go.
> PackageKit n'est pas sponsorisé, mais le projet semble intéresser Red Hat, openSUSE
Le mainteneur est un développeur Red Hat il me semble.
Pour l'instant il n'est pas prévu que PackageKit remplace Pirut, etc. PackageKit sera fournit avec F9.
> te donne rendez vous pour le prochain, qui traitera de façon pas trop superficielle les algorithmes de résolution des dépendances, les limites actuelles et peut être quelques solutions prometteuses.
Merci pour le temps que tu consacres à faire ces bons articles.
Mais il me semble qu'un aspect est "négligé". C'est la qualité, une vue d'ensemble. Fedora ne permet pas à tout le monde de compiler sur koji pour des raisons de qualité. Un paquet est accèpté qu'après un audit sérieux du paquet (licence, état de l'art, es-ce une technologie obsolète ou pas, etc).
Ça s'inscrit dans un projet qui a des objectifs. Ça fédère dans gens autour de ces objectifs. Ce n'est pas une libre service. C'est un mal et c'est un bien. Limiter les fonctionnalités (par exemple ne pas permettre à tout le monde de compiler) n'est pas forcément un mal.
Pour les algorithmes de résolution, il y a des "astuces" qui semblent moins sucker. Mais au niveau rigueur, c'est plus douteux (par exemple smart qui downgrade un paquet pour en installer un autre).
Qui peut le plus plus peut le moins. Mais ce n'est pas forcément pour le meilleur.
[^] # Re: Re:
Posté par Spyhawk . Évalué à 3.
>Et pourquoi pas des milliers !
>Pour Fedora (compilation i386, x86_64, ppc et ppc64), il n'y a "que" dix machines (certaines virtuelles) :
>http://koji.fedoraproject.org/koji/hosts
>Et tout y est compilé, ce n'est pas que dédié "extras". La distribution y est compilé, les mises à jours, les contributions externes, rawhide, etc.
Tu as raison, je suis allé un peu vite. De mémoire, il me semblait avoir lu quelque part le nombre de 126 machines (irc ?). Je n'ai pas réussi à retrouver une source pour ce nombre.
Cependant, sur le blog d'un développeur KDE employé par SuSE/Novell [1], j'ai trouvé le nombre de "plus de 120 CPUs" qui me laisse penser que ma mémoire était bonne,
Alors effectivement, ce n'est pas plus de 120 machines (du moins je pense, je n'ai aucune idée du nombre de CPU par machine, et encore moins du nombre de core par CPU...).
Ma seconde erreurs est d'avoir écrit tacitement que ces machines ont toutes été données par AMD. C'est bien sûr l'ensemble des machines (don AMD + le parc existant) qui représente ces 120+ CPUs.
>> Le Build Service a de multiples avantages :
>> - Il resoud automatiquement les dépendances des paquets compilés.
>Ce n'est pas un avantage, c'est une nécessité.
>> Ainsi, si un paquet B dépend d'un autre paquet A, le paquet B va être automatiquement recompilé si la dépendance A est modifiée et recompilée.
>"Foutaise".
>Presque tous les paquets dépendent de libc ou gcc. Si libc ou gcc est changé, tu nous expliques que le build système va recompiler tous les paquets !
>Et comment tu fais pour gérer les versions ? Ben oui, il va y avoir des toto-1.0-1 avec différent libc et gcc. Ça sucks.
>Bref, ce truc je n'y crois pas.
C'est pourtant ce qu'il se passe. Heureusement, la libc et gcc ne changent pas trop pour une version stable, mais il en est autrement pour les builds Factory (la version de dev opensuse).
Prenons un exemple : Je choisis totalement arbitrairement le dépôt personnel d'un utilisateur lambda : http://download.opensuse.org/repositories/home:/Spyhawk/.
Cet utilisateur lambda a compilé quelques paquets pour une version stable (10.3) et la version Factory. Je sais, de source sûre, que cet utilisateur a compilé ces paquets dans le mois d'octobre 2007 et n'y a pas touché depuis.
Les paquets du répertoire 10.3 sont datés d'octobre 2007. En revanche, les paquets Factory sont datés de deux jours (samedi 8 mars 2008 vers 07h55 - mes sources indiques que l'utilisateur lambda cité dormait encore), soit grosso modo la date de la dernière recompilation de la Factory. Et c'est comme ça pour tous les builds Factory.
Aussi, la Factory est recompilée (quasi) entièrement une à deux fois par semaine (à chaque mise à jour, et pas seulement lors du changement de la libc ou gcc). Ca permet de s'assurer que tous les paquets fonctionneront (avec le désavantage e lancer une compile après l'autre.. ).
J'imagine que les paquets compilés pour une version stable sont recompilés lors d'une mise à jour de sécurité (un rapide coup d'oeil à la liste des maj de sécu me montre qu'il n'y a pas eu d'update de la libc / gcc de octobre à ce jour). Ou alors, peut être qu'une simple faille corrigée dans la libc/gcc ne fait pas perdre de son caractère compatible (?).
Enfin, il me semble qu'entre la ligne du "c'est une nécessité" et la suivante "Foutaise" qui parle du même sujet, il y a une subtilité qui m'échappe..
>Mais il me semble qu'un aspect est "négligé". >C'est la qualité, une vue d'ensemble. Fedora ne permet pas à tout le monde de compiler sur koji pour des raisons de qualité. >Un paquet est accèpté qu'après un audit sérieux du paquet (licence, état de l'art, es-ce une technologie obsolète ou pas, etc).
>Ça s'inscrit dans un projet qui a des objectifs. Ça fédère dans gens autour de ces objectifs. Ce n'est pas une libre service. >C'est un mal et c'est un bien. Limiter les fonctionnalités (par exemple ne pas permettre à tout le monde de compiler) n'est pas forcément un mal.
Effectivement, je n'ai pas trop parlé de cet aspect "qualité". Après un rapide aperçu du BS, je voulais surtout mettre le doigt sur la possibilité de compiler des paquets autres qu'openSUSE (ce qui est surement plus intéressants pour la majorité des leceturs linuxfr), et surtout que la démarche entreprise par Fedora est la même pour les toutes autres distributions j'imagine.
Pour openSUSE, la seule différence est que les paquets "grands publics" (/repositories/home:/user) sont déjà dispo. Mais ils doivent bien sûr être approuvés avant d'entrer dans les dépôts semi-officiels contenus dans /repositories/projet (ex:KDE:/Backport) ou communautaires (ex: KDE:/Community).
Pour ceux que ça intéresse, cette présentation[2] fournit un schéma montrant bien le processus (slide 17). Le reste du PDF aborde les principes généraux du BS et quelques limites du BS dont je n'ai pas parlés. Egalement, le wiki openSUSE est assez exhaustif.
Pour smart, c'est justement le comportement que tu décris que je citais comme "efficacité agressive", mais je reprendrais ça ce week end (si j'ai le temps..)
[1] http://www.kdedevelopers.org/node/2850
[2] http://bw.uwcs.co.uk/talks/OBSTalk_WUGLUG.pdf
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
CPU ou core ?
Si c'est core et pour des quadri-cores on tombe à 40 machines (ce qui reste impressionnant).
> Je sais, de source sûre, que cet utilisateur a compilé ces paquets dans le mois d'octobre 2007 et n'y a pas touché depuis.
Mouaif...
$ $ rpm -q --changelog -p kbde-1.1.6-9.36.src.rpm
attention: kbde-1.1.6-9.36.src.rpm: Entête V3 DSA signature: NOKEY, key ID 76edc1ff
* lun mai 14 2007 <valery_reznic@users.sourceforge.net> 1.1.5-1
- no real change - just to match kbde-driver version
Le dernier log n'est pas à jour (1.1.5-1 alors que le paquet est 1.1.6-9.36).
Le src.rpm a été reconstruit le 8 mars.
$ rpm -q -i -p kbde-1.1.6-9.36.src.rpm | grep "Build Date"
attention: kbde-1.1.6-9.36.src.rpm: Entête V3 DSA signature: NOKEY, key ID 76edc1ff
Release : 9.36 Build Date: sam 08 mar 2008 07:54:34 CET
> Factory sont datés de deux jours (samedi 8 mars 2008 vers 07h55 - mes sources indiques que l'utilisateur lambda cité dormait encore), soit grosso modo la date de la dernière recompilation de la Factory. Et c'est comme ça pour tous les builds Factory.
Ce qui ne montre rien. Pour koji et probablement comme pour OpenSuSE, les requêtes de construction de paquet sont empilés dans une file. Ce n'est pas excécuté de suite.
> Aussi, la Factory est recompilée (quasi) entièrement une à deux fois par semaine
J'y crois pas. Mais si je me trompe, tant mieux.
> Enfin, il me semble qu'entre la ligne du "c'est une nécessité" et la suivante "Foutaise" qui parle du même sujet, il y a une subtilité qui m'échappe..
C'est une nécessité que le système de build gère les dépendances _lors_ de la construction.
Exemple pour mock (compilation de galeon). Mock est utilisé par koji (Fedora) :
$ mock --rebuild --root=fedora-8-x86_64 .../SRPMS/galeon-2.0.4-1.fc8.2.src.rpm
: Installing:
gcc-c++ x86_64 4.1.2-33 fedora 3.7 M
make x86_64 1:3.81-10.fc8 fedora 482 k
redhat-rpm-config noarch 9.0.1-1.fc8 fedora 52 k
rpm-build x86_64 4.4.2.2-7.fc8 updates-released 303 k
tar x86_64 2:1.17-7.fc8 updates-released 911 k
unzip x86_64 5.52-6.fc8 updates-released 152 k
Installing for dependencies:
ConsoleKit-libs x86_64 0.2.3-3.fc8.1 updates-released 14 k
MAKEDEV x86_64 3.23-1.2 fedora 135 k
...
Transaction Summary
=============================================================================
Install 98 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 95 M
Ceci est l'installation du minimum.
Puis mock installe ce qui est spécifique pour la construction de galeon :
=============================================================================
DEBUG util.py:250: Package Arch Version Repository Size
=============================================================================
Installing:
ccache x86_64 2.4-11.fc8 fedora 53 k
firefox-devel x86_64 2.0.0.12-1.fc8 updates-released 3.5 M
gettext x86_64 0.16.1-12.fc8 fedora 1.5 M
gnome-desktop-devel x86_64 2.20.3-1.fc8 updates-released 38 k
intltool x86_64 0.36.2-1.fc8 fedora 89 k
Installing for dependencies:
ConsoleKit x86_64 0.2.3-3.fc8.1 updates-released 56 k
GConf2 x86_64 2.20.1-1.fc8 fedora 1.6 M
...
Transaction Summary
=============================================================================
Install 202 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 115 M
Rien que pour construire Galeon, il y a 300 (!) dépendances !!! Soyons gentil et disons qu'on trouve ses 300 dépendances dans 100 paquets src.rpm.
Tu nous expliques que Galeon va être recompiler dès qu'un de ses 100 paquets est recompilé. Ceci est pour moi de la "foutaise".
Enfin, il y a les problèmes de dépendance cyclique et j'aimerai bien savoir comment fait OpenSuSE pour gérer ça...
Et que ce passe-t-il si une mauvaise version de libc est introduite ?
Tout est recompilé, tout échoue, et tout est cassé.
> qu'il se passe. Heureusement, la libc et gcc ne changent pas trop pour une version stable, mais il en est autrement pour les builds Factory
Changement gcc (une fois par semaine) :
http://koji.fedoraproject.org/koji/packageinfo?packageID=40
Changement glibc (une fois toutes les deux semaines) :
http://koji.fedoraproject.org/koji/packageinfo?packageID=57
Et non Fedora ne recompile pas tout dans ce cas.
*Parfois* Fedora fait des recompilations de tous les paquets (typiquement lors d'un changement majeur de version de compilo, etc). Quand ça arrive, ça devient un projet à lui seul tellement c'est lourd à gérer (beaucoup de paquet plante à la compilation, etc).
En passant, la compilation d'OOo chez Fedora (i386/x86_64/ppc/ppc64) prend 8 heures ! Nombre de dépendance 387 !
Si à chaque changement d'une dépendance il faut recompiler OOo, ben tu le recompiles tous les 2 jours au minimum
Mais il y a "pire", c'est la bande passante. Les utilisateurs (mirroirs compris) ne vont absolument pas aprécier d'avoir à downloader des centaines de Mo car un paquet a été mis à jour.
Fedora ne recompile pas systématiquement et c'est déjà vraiment, vraiment limite (pas seulement pour Fedora, mais pour les mirroirs et les utilisateurs). Donc je ne crois pas qu'OpenSuSE recompile tout si une dépendance change. Ou alors OpenSuse est sur une autre planète et ce n'est pas la mienne.
[^] # Re: Re:
Posté par Spyhawk . Évalué à 1.
Et effectivement, ça pose le problème de la bande passante.
Je ne sais pas comment font les miroirs qui relaient la Factory (comme indiqués, tous les mirroirs openSUSE n'ont pas le même contenu), mais pour les utilisateurs/testeurs Factory, c'est 1 à 3 Go (ou plus) de mise à jour par ~semaine.
Pour ce qui est des dépendances cycliques, j'en sais fichtrement rien (moi et la compile de paquets... comme tu l'as vu ceux que je propose sont de mauvaises qualité, mais c'etait juste un test pour me faire la main :) )
[^] # Re: Re:
Posté par Spyhawk . Évalué à 1.
Outre par AMD, openSUSE est sponsorisé par IP Exchange Germany, qui procure toute l'infrastructure réseau (bande passante, gros débits). Je ne sais pas dans quelle proportion, mais c'est surement un facteur décisif pour la bonne marche de l'oBS.
# Parce que Linux le vaut bien ?
Posté par eastwind☯ . Évalué à 0.
top moumoute de programme ré-vo-lu-tionaire.Tu as un problème avec tes cheveux ? C'est l'effet L'Oréal / Chegevara ?
[^] # Re: Parce que Linux le vaut bien ?
Posté par eastwind☯ . Évalué à 0.
# ZeroInstall lib dynamqiue
Posté par eastwind☯ . Évalué à 2.
On clique et le paquet s'installe (télécharge et installe les dépendances) avec ses librairies statistiquement liés dans /home. Certains vont plus loin, en utilisant les librairies dynamiques du système si elles sont détectées sur le système cible, ou essai même d'intéragir avec le package manager en place pour éviter les doublons de programmes.
Les inconvénients de cette méthode sont bien sur ces librairies statiques, à contre courant du principe meme du package management
C'est le cas de ZeroInstall mais comme celui ci détècte les libs déjà présente il n'y pas de redondance .. Sinon la question est de savoir si les paquets de Lib nécessaire au soft en question ne peuvent pas être considérer par le package manager comme un lib dynamique ?
Quel est le niveau d'interaction entre ZeroInstall et le package manager ?
[^] # Re: ZeroInstall lib dynamqiue
Posté par Nerdiland de Fesseps . Évalué à 3.
Le gros problème de ZeroInstall actuellement, c'est que les programmes doivent gérer le déplacement des exécutables (binary relocation) vu qu'il est impossible de savoir où se trouveront les fichiers. Ainsi Scribus, qui inscrit les chemins en dur lors de la compilation, ne fonctionne pas.
# PackageKit: le début de la collaboration inter-distribution ?
Posté par GeneralZod . Évalué à 2.
Ce qui est intéressant c'est de voir comment Richard Hugues a mené son projet et comment il a impliqué d'autres développeurs venant d'autres distributions.
PackageKit sera inclus dans Fedora 9 en tant que gestionnaire alternatif. http://fedoraproject.org/wiki/Features/PackageKit
Interview de Richard Hugues et Robin Norwood à propos de PackageKit.
http://fedoraproject.org/wiki/Interviews/PackageKit
Les slides de la présentation de Richard Hugues au FOSDEM:
http://people.freedesktop.org/~hughsient/public/introduction(...)
[^] # Re: PackageKit: le début de la collaboration inter-distribution ?
Posté par IsNotGood . Évalué à 2.
Faut pas s'emballer. Si ça arrive ça ne sera probablement pas avant F11.
L'intérêt dans le cas de l'installeur est très limité. PackageKit ne remplace pas yum, c'est plus de complexité pour l'installeur (dbus, des tas de librairie, ConsoleKit, etc).
[^] # Re: PackageKit: le début de la collaboration inter-distribution ?
Posté par GeneralZod . Évalué à 2.
De plus, il faudra convaincre Jeremy Katz avant qui aura de nombreux arguments à mettre en avant (dont ceux que tu cites).
[^] # Re: PackageKit: le début de la collaboration inter-distribution ?
Posté par IsNotGood . Évalué à 2.
Je ne sais pas ce qu'il t'a fait...
Et pourquoi tu tiens tant à voir PackageKit dans Anaconda ?
L'installeur c'est "one shot". Ça doit marcher en mode non intéractif et en mode texte.
Où est l'absolue nécessité d'avoir PackageKit dans Anaconda ?
[^] # Re: PackageKit: le début de la collaboration inter-distribution ?
Posté par GeneralZod . Évalué à 2.
Je n'ai rien contre Jeremy Katz qui fait de l'excellent boulot.
Si on projete d'intégrer PackageKit dans Anaconda, il faut bien à un moment ou à un autre convaincre le mainteneur d'Anaconda, non ? À ce sujet, je n'ai aucun parti pris, l'interface actuelle dans Anaconda (Pirut) fait très bien son boulot et il y a tout un tas de bonnes raisons (dont celle que tu as cité) pour ne pas la remplacer.
Autant, je tiens à ce que PackageKit remplace Pirut/Synaptic & cie en tant que gestionnaire de paquet standalone par défaut non seulement dans Fedora mais dans d'autres distributions, autant, pour Anaconda, je demande à voir l'intérêt.
[^] # Re: PackageKit: le début de la collaboration inter-distribution ?
Posté par IsNotGood . Évalué à 2.
C'est la seconde fois que du nomme explicitement Jeremy Katz dans des propos relatifs à PackageKit.
Le faire intervenir aujourd'hui (encore) parait pour le moins "saugrenu".
Et pourquoi que lui ? Es-ce que Fedora dans son ensemble est convaincu que PackageKit va tout remplacer à moyen terme ?
Je ne crois pas.
Ni aura-t-il pas quelques rétissances à ajouter PackageKit à Anaconda alors qu'Anaconda bouffe déjà un peu trop de mémoire ? Et ceci (ainsi que d'autres aspects) va au-delà de seulement l'avis de Jeremy Katz.
Et qu'on se comprenne bien, je n'ai rien contre PackageKit. Je me suis peu documenté, mais il parait pour le moins bien conçu et ergonique. Il a les qualités pour ralier d'autres développeurs de diverses distributions et c'est vraiment excellent.
Mais programmer l'enterrement de pirut/etc aujourd'hui est saugrenu.
Yum (avec yum-updatesd, les applets qui vont bien, pirut, etc) a mis des années (yum est dans Fedora par défaut depuis FC1 !).
Il ne faut pas enterrer pirut/etc à priori. Mais à posteriori. C-à-d après que PackageKit (ou un autre) ait prouvé sa valeur. D'autant plus que pour l'instant Fedora (et/ou Red Hat) n'a pas donné de signe qui indique que Fedora a une vision pour PackageKit (contrairement à Xen vs KVM par exemple). Pour l'instant Fedora va donner sa chance à PackageKit pour F9 (et suivant évidemment). PackageKit le mérite largement et c'est totalement dans l'esprit Fedora.
Si tu fais une news sur F9, n'hésite pas à mettre un projecteur (et un gros) sur PackageKit.
Mais ne sous-entend pas que les ambitions de PackageKit sont contrariées par Jeremy Katz :-)
[^] # Re: PackageKit: le début de la collaboration inter-distribution ?
Posté par GeneralZod . Évalué à 2.
Je ne le pense pas une seconde.
La première fois que je l'ai cité c'était dans un contexte plus centré sur l'ergonomie de Pirut.
> Si tu fais une news sur F9, n'hésite pas à mettre un projecteur (et un gros) sur PackageKit.
Ce sera fait quand les ambassadeurs francophones rédigeront la news. :o)
D'ailleurs Anaconda sera probablement à l'honneur ainsi qu'un autre projet Fedora très funky ;-)
# Fedora
Posté par guitouu . Évalué à 2.
Tu présentes le One-clic-Install comme une super nouveauté.
Ok c'est bien mais ca ne me semble pas unique...
Voila mon experience :
Je suis sous Fedora 8 et quand je clic sur un simple lien RPM sur internet, il est telechargé, on me demande le mot de passe et une interface graphique de yum se lance pour me demande de confirmer et me propose d'installer si besoin certaines dépendances ... il y a 3 clics et un mot de passe.
Je ne vois pas ce que le one clic install fait de plus ...
Il y a aussi la variante avec le repository. Yum a été concu pour qu'on puisse installer un repo via l'installation d'un RPM ...
Donc je prends un exemple simple, Adobe (pour le flash) :
je vais sur le site de flash, je clic sur le RPM repo fedora, il se telecharge, mot de passe et s'installe. Et si j'ouvre mon programme manager, le repository est bien installé et deja activé, flash est dispo, je n'ai plus qu'a cliquer dessus... et des qu'une mise a jour sera faite sur le site de adobe, je serai automatiquement mis a jour...
De la meme facon, j'installe le repo de livna (tt le "non free" pour fedora), le rpm s'installe en activant "stable" et en desactivant "testing" et "dev" (aux testeurs ou developpeur de se l'activer en 2 clic si besoin) ...
Ca me parait tres complet... je ne vois pas le besoin de plus comblé par opensuse meme si je n'ai rien contre, au contraire j'ai de la sympathie pour les distributions mal aimées en france, car fedora en est une et que j'en suis fan :)
[^] # Re: Fedora
Posté par IsNotGood . Évalué à 3.
> Je suis sous Fedora 8 et quand je clic sur un simple lien RPM sur internet, il est telechargé, on me demande le mot de passe et une interface graphique
C'est un truc qui existe depuis Red Hat 7.2 !
À l'époque c'était redhat-config-package (pas terrible ceci dit) qui était utilisé.
> Tu présentes le One-clic-Install comme une super nouveauté.
Ben ceux qui n'ont jamais utilisé Red Hat/Fedora le pensent.
[^] # Re: Fedora
Posté par guitouu . Évalué à 2.
Mais tu es sur que ça lançait yum et que ça faisait la résolution des dépendances?
Il me semble que dans le passé de Fedora, ça lançais simplement une interface graphique qui installait le rpm avec l'outil rpm sans passer par yum ou une quelconque résolution des dépendances...
Mais peut etre que je me goure et que je n'ai jamais eu l'occasion d'observer ça...
En tout cas, cette capacité n'est pas suffisamment utilisée à sa juste valeur : on devrait avoir sur nos sites d'aide Fedora, comme pour OpenSuse, des liens directs vers des RPM de nos repository pour aider les gens débutants à installer un package précis en un clic pendant qu'il lit une doc sur le net. Genre, "xmms est vieux, voila la nouvelle génération : audacious ( cliquer ici pour une installation immédiate: http://livna.org/repo/F8/audacious.x.X.y.f8.rpm )
[^] # Re: Fedora
Posté par GeneralZod . Évalué à 3.
De plus, il vaut mieux apprendre aux nouveaux venus à se servir proprement des outils adaptés. Même si les dépôts sérieux signent leurs paquets, la généralisation du OneClick Install signifierait le retour du "dependency hell", je t'installes machin du dépôt X, puis truc du dépôt Y etc ... C'est bête mais c'est un comportement typiquement Windozien !
[^] # Re: Fedora
Posté par Spyhawk . Évalué à 1.
Par contre, et suite aux commentaire ci-dessus, je note qu'il y a quand même une petite différence.
L'OCI d'openSUSE est conçu plus comme une couche d'abstraction : les liens OCI ne pointent pas directment vers le fichier RPM/deb en question, mais sur un fichier XML. Ce fichier XML peut décrire, au choix :
- l'installation d'un dépôt
- l'installation d'un paquet (et résolution dépendance), indépendamment de sa version
- l'installation d'un groupe de paquets d'un dépot
- l'installation d'un groupe de paquets situés sur plusieurs dépôts (pratique pour installer en quelques clics tous les fichiers nécessaires au "débridage" d'openSUSE via les repo Packman et VideoLan, par exemple)
- etc, etc. On peut imaginer toute sorte de combinaison plus ou moins utile selon la situation.
Chaque lien fichier XML peut en outre être muni d'option, tel que de garder ou non le dépot après installation des fichiers, une section "avancée" qui permet de sélectionner individuellement certains paquets d'un groupe de paquets par défaut, ...
Mais c'est surtout sa mise en avant, son utilisation par défaut et toute l'adaptation de l'infrastructure autour (wiki / moteur de recherche officiels et communautaires) qui ajoute cette plue value à la distribution.
Et je pense que toute les distributions auraient a gagner en utilisant "plus" (ou de façon native pour .deb) ce système qui n'est "pas une nouveauté" (enfin, Fedora ne semble pas intéressé par ce système "à la kéké", malgré qu'il est fonctionnel depuis des lustres :) )
@GeneralZod > Je ne pense pas que cette méthode "à la windows" déclencherait un retour au "dependancy hell", tant que l'environnement autour de la distribution est adaptée : les moteurs de recherche de paquets par défaut indiquent clairement le dépôt utilisé. C'est aussi plus facile quand la majorité de l'infrastructure est centralisée (oBS) et qu'il n'y a pas x dépôts disparates (websphere openSUSE plutôt limitée comparée à d'autres distributions).
Par contre, il est clair que mélanger des dépôts 10.3 avec des dépôts Factory ça risque de faire mal...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.