La plupart des distributions se basent sur un ensemble de paquets (contenant logiciels, bibliothèques, et autres) liés entre eux par différents types de dépendances. Les formats de paquets les plus répandus sont les fichiers deb (Debian et dérivées), et rpm (Red Hat et dérivées). Les outils dpkg et rpm permettent de manipuler les paquets en local. La couche du dessus, qui contient des outils comme apt et yum, permet la résolution des dépendances. L'utilisateur peut donc choisir les paquets qu'il souhaite installer, et les dépendances sont résolues afin que les paquets nécessaires soient installés et que les éventuels paquets en conflit soient supprimés. L'outil de résolution des dépendances a pour seul but de répondre aux besoins de l'utilisateur sans enfreindre les règles de dépendances et de conflits définies. Éventuellement, cet outil peut répondre qu'il n'existe aucune solution au problème posé...
Dans les faits, il existe différents solveurs de dépendances différents entre les distributions, et même au sein de chaque distribution. Dans la plupart cas, il n'existe pas de bonne raison à cet état de fait. Seuls certains domaines spécifiques (par exemple, l'embarqué) peuvent nécessiter un algorithme de résolution différent. Lors de sa conférence intitulée « Cross-distro dependency resolution: reusing solvers among distros », Stefano Zacchiroli, développeur Debian, présente le travail réalisé dans le but de créer un format standard de description des problèmes de résolution de dépendances. Ceci a pour but de pouvoir abstraire ces derniers en omettant les spécificités de chaque distribution (par exemple, transformer les différents niveaux de liens entre les paquets dans Debian : Depends/Recommends/Suggests/Conflicts/Replaces/etc. et la notion de paquets virtuels), et donc de pouvoir travailler sur des solveurs performants et éventuellement utilisés largement par les différentes distributions, en évitant la duplication du travail.
Plus de détails dans la suite de la dépêche
NdM : Merci à Adrien Cunin pour son journal à l'origine de la dépêche. Cette abstraction correspond au format CUDF, acronyme de Common Upgradability Description Format. Un fichier CUDF est un simple fichier texte basé sur la RFC 2822, listant des paquets (chacun ayant un certain nombre de propriétés), le tout organisé en 3 sections :
- l'univers des paquets, c'est-à-dire la liste des paquets disponibles dans les dépôts ;
- les paquets installés ;
- la requête de l'utilisateur.
Enfin, l'équipe derrière CUDF souhaite collecter des données auprès des utilisateurs de systèmes de paquets afin de constituer une base de cas d'utilisation réels sur les problèmes de résolution de dépendances. De plus, une compétition sera organisée entre les différents algorithmes de résolution proposés.
Tout ce travail, même s'il peut sembler actuellement abstrait, pourrait permettre à terme d'améliorer les systèmes de paquets dans les distributions.
Aller plus loin
- Conférence sur le site du FOSDEM (5 clics)
- CUDF (16 clics)
- CUDF Primer (4 clics)
- Debian-CUDF (7 clics)
- Journal à l'origine de la dépêche (8 clics)
# Paquets universels ?
Posté par Dreamkey . Évalué à 4.
J'avoue ne pas connaître leur fonctionnement et même si c'est possible en théorie, mais j'ai remarqué que certain trouvait que de devoir générer un paquet par distribution était dommageable pour la communauté en général.
[^] # Re: Paquets universels ?
Posté par Folken Laëneck . Évalué à 3.
Ouai, utopie c'est peut-être bien le bon mot : génial mais irréaliste :(
[^] # Re: Paquets universels ?
Posté par Carl Chenet (site web personnel) . Évalué à 3.
Et ça sort d'où cette théorie ?
[^] # Re: Paquets universels ?
Posté par Alex G. . Évalué à 9.
[^] # Re: Paquets universels ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 8.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Paquets universels ?
Posté par Aurélien Bompard (site web personnel) . Évalué à 5.
Et encore, ça ne résoudrait pas grand chose. On pense souvent que le problème vient du fait que le format DEB et le format RPM sont différents, mais quand on creuse on se rend compte que c'est faux. Exemple : je suis sur Fedora, je vais chercher sur rpmfind.net un paquet lambda qui correspond à mon application manquante. Il se trouve que le paquet vient de chez SuSE ou Mandriva, sur une version n-2, et donc forcément quand j'essaye de l'installer, je me fais jeter.
Et pourtant, c'est bien un RPM.
Le problème de compatibilité entre les paquets des distributions ne vient pas du format, mais du fait qu'ils sont compilés avec des bibliothèques différentes, pas forcément compatibles, avec des options différentes, etc.
En fait, le problème vient du fait que les paquets viennent de distributions différentes.
C'est là d'ailleurs le fond du problème : supposer que n'importe quel RPM peut s'installer sur n'importe quelle distribution basée sur RPM, c'est ignorer (voire nier) le travail de mise en cohérence fait par la distribution.
Et au passage, les deux formats ne sont pas si différents l'un de l'autre. En gros une archive, des méta-données décrivant le paquet et ses dépendances, et des scripts à exécuter autour de l'installation et de la désinstallation du paquet. On fait tout un foin sur les incompatibilités entre ces deux formats, alors que le problème n'est pas là.
Il y a selon moi quatre solutions au problème pour un distributeur de logiciel externe, si on exclut l'inclusion dans la distribution bien sûr :
- la compilation statique
- la fourniture, avec le programme, de ses bibliothèques dynamiques dans un dossier à part. C'est ce qui se fait le plus en ce moment (mozilla, jeux, etc.), mais c'est pas beaucoup mieux que la compilation statique
- l'utilisation d'un format spécifique type autopackage ou klik (le truc de SuSE qui monte dynamiquement une image iso)
- la distribution sous forme de source, avec peut-être un système pour créer automatiquement un package en local (type checkinstall)
Aucune de ces solutions ne semble miraculeuse, sachant qu'elles sont toutes un pis-aller à l'inclusion dans la distribution.
Autopackage n'a jamais vraiment décollé, c'est dommage je trouve. Des avis ?
[^] # Re: Paquets universels ?
Posté par jbbourgoin (site web personnel) . Évalué à 2.
Problème qui est aussi celui des mises à jour.
Cela dit, l'usage quasi exclusif des bibliothèques statiques me semble être une très mauvaise idée : lourdeur, bugs, bazar etc.
Autopackage semblait être une bonne solution mais souffrait du manque d'intégration dans les distributions.
Il me vient une idée :
Les distributions pourraient peut-être proposer, pour les logiciels les plus couramment utilisés, le choix entre l'installation de la version "statique" et de la version "dynamique".
"firefox" & "firefox-static", par exemple.
Le logiciel d'installation "classique" proposerait le choix, le logiciel "simplifié" ferait le choix par défaut de la version statique. Ainsi le "end-user" pourrait bénéficier des maj de firefox rapidement.
C'est ici qu'une normalisation telle que le CUDF serait intéressante, ainsi qu'un format standard (type rpm LSB) associé à l'obligation d'installer le logiciel dans le répertoire /opt (par exemple).
Cela ne concernerait que les paquets "statiques". Les logiciels d'installation de paquet se contentant de suivre les recommandations pour ces paquets, tout en les séparant clairement des paquets "standards" (installation dans /opt). Ces logiciels s'occuperaient de la conversion automatique du rpm standard au format idoine.
Tout cela a sans doute été déjà pensé, déjà contré, et déjà enterré ;)
[^] # Re: Paquets universels ?
Posté par FreeB5D . Évalué à 1.
-une version de Qt pour KDE (c'est un logiciel populaire)
-une version de Qt pour Amarok (idem)
-une version de Qt pour K3B (idem)
-une version de Qt poru Skype (idem)
-une version de GTK pour Firefox (idem)
-une version de GTK pour Pigin (idem)
?
Pas moi . Même si j'ai 2 Go de RAM, je préfère m'en servir pour compiler ou pour des jeux .
[^] # Re: Paquets universels ?
Posté par jbbourgoin (site web personnel) . Évalué à 2.
Relisez-moi, je ne préconisais pas l'installation systématique d'applications avec bibliothèques statiques.
Je me demandais si offrir le choix entre dynamique et statique, sachant que les applis "statiques" seraient plus régulièrement mises à jour et proposées par défaut dans l'interface d'installation "pour-les-nuls", ne seraient pas une solution relativement facile et rapide à mettre en place en ce qui concerne le principal reproche que l'on fait aux distros Linux :
1) soit d'être "statique" (Debian stable/testing, ubuntu, fedora etc.) et de ne proposer que des applis vieilles.
2) soit d'être "rolling-release" (Debian Sid, Gentoo, Arch etc.) mais d'être beaucoup moins solides.
L'idée étant de proposer le choix entre libs statiques et dynamiques uniquement pour les applis populaires et dont il est bon d'avoir des maj fréquentes (openoffice, firefox etc.).
Les applis "statiques" seraient installées dans "/opt" ce qui permettrait d'envisager une standardisation sur ce point et de mettre en place, enfin, des paquets cross-distro. Dès lors les trucs comme CUDF et LSB-rpm commenceraient à avoir un intérêt certain.
# Pas convaincu
Posté par Changaco (site web personnel) . Évalué à 2.
- les paquets n'ont pas les mêmes noms selon la distribution
- les performances, à moins de stocker la base des paquets dans ce format il faut la transcoder à chaque opération
- encore un nouveau format et donc un nouveau parseur, c'est pourtant pas le choix qui manque dans l'existant
[^] # Re: Pas convaincu
Posté par Victor . Évalué à 8.
L'idée ici est simplement de proposer une abstraction sur les formats existants de telles sorte qu'on puisse produire un algorithme de résolution de dépendance générique qui puisse ensuite être utilisé par les différents formats.
Il n'est pas question d'avoir un ensemble de paquet communs, une base de donnée commune ni un format commun.
[^] # Re: Pas convaincu
Posté par Changaco (site web personnel) . Évalué à 1.
L'abstraction c'est bien quand c'est justifié et utile, sinon ça ralentit pour rien.
Il n'est pas question d'avoir […] un format commun.
Bah si, un format de transaction commun à passer à un résolveur plus ou moins commun, ou alors je n'ai rien compris.
[^] # Re: Pas convaincu
Posté par MrLapinot (site web personnel) . Évalué à 10.
L'idée c'est que résoudre un problème de dépendances, c'est NP-complet (donc très très difficile, nécessitant beaucoup de puissance de calcul ou alors des optimisations astucieuses si tu veux obtenir un résultat avant la fin de l'Univers). Pour l'instant, chaque distribution, et même pire, chaque gestionnaire de paquet (il peut y en avoir plusieurs par distribution, par exemple apt-get et aptitude) fait son truc dans son coin. C'est complètement sous-optimal (duplication des efforts, pas de partage des connaissances, résultats issus de bidouillage plutôt que de recherche théorique avancée dans le domaine).
La solution proposée, c'est un format qui soit capable de décrire un problème de dépendances. On se moque que les paquets s'appellent xyzpqrt ou gnome-vs-kde : chaque gestionnaire de paquet pourrait traduire sa liste de paquets dans ce format, puis passer le problème à un outil externe, unique, performant, indépendant du système de paquets utilisé. Le truc il fait sa tambouille magique et il répond, dans le même format commun standardisé : le gestionnaire de paquet n'a plus qu'à décoder la solution et la proposer à son utilisateur favori.
Et ça marche déjà (sans être aussi efficace et automatisé que je le décris toutefois) : http://www.dicosmo.org/MyOpinions/index.php/2010/05/13/102-t(...)
[^] # Re: Pas convaincu
Posté par Changaco (site web personnel) . Évalué à -2.
Quant au fait qu'on y gagnerait en performance je répète ce que je disais dans mon premier message, à moins de garder la base des paquets dans le format du résolveur il y aura un coup de transcodage à chaque opération.
J'ai également un doute sur l'utilité de la chose pour une distribution en rolling-release et do it yourself style Arch Linux où il y a peu de conflits. Sortir l'attirail de recherche automatique de solution ne serait pas forcément bénéfique, quand bien même l'algorithme de résolution serait plus efficace.
[^] # Re: Pas convaincu
Posté par Dr BG (site web personnel) . Évalué à 6.
[^] # Re: Pas convaincu
Posté par Dr BG (site web personnel) . Évalué à 2.
[^] # Re: Pas convaincu
Posté par FreeB5D . Évalué à 2.
[^] # Re: Pas convaincu
Posté par Dr BG (site web personnel) . Évalué à 2.
[^] # Re: Pas convaincu
Posté par Thomas Douillard . Évalué à 4.
# Ne pas oublier urpmi
Posté par Pierre Jarillon (site web personnel) . Évalué à -1.
Je pense que CUDF arrive un peu tard et a maintenant peu de chances d'être intégré à apt ou urmpi qui sont actuellement les gestionnaires de paquets les plus performants.
[^] # Re: Ne pas oublier urpmi
Posté par Changaco (site web personnel) . Évalué à 5.
Troll détecté.
# Installation des paquets et des dépendances
Posté par mgoeminne (site web personnel) . Évalué à 9.
Je m'explique : on souhaite installer un ensemble de paquets. Ces paquets ont un ensemble de dépendances. Ces dépendances étant elles-même des paquets, elles peuvent avoir leurs propres dépendances, etc. Au final, on se retrouve avec des paquets stratifiés : les paquets dont toutes les dépendances sont présentes (ou qui n'en n'ont pas) permettent d'installer les paquets qui dépendent d'eux.
Il en résulte qu'il est possible de commencer par récupérer localement une partie choisie des paquets voulus (appelons ça une vague), et de les installer pendant que la récupération des paquets dépendant des premiers commence. Cette approche a l'avantage de ne pas faire dormir le processeur pendant le téléchargement, et de ne pas négliger la bande passante pendant que le processeur (et autres périphériques) moulinent pour installer les paquets. Donc on gagne du temps, et pour peu que l'installation de chaque vague de paquets se déroule correctement, les dépendances sont respectées. Si l'installation d'une vague échoue, seuls les paquets dépendant des paquets de la vague seront impactés.
A ma connaissance, aucun outil ne propose ça. Y a-t-il des pistes dans ce sens?
[^] # Re: Installation des paquets et des dépendances
Posté par Changaco (site web personnel) . Évalué à 2.
Je pense qu'une raison pour laquelle ça n'existe pas est que la parallélisation est souvent plus pénible à coder. Il est également plus difficile de rendre compte de l'avancement de travaux parallèle dans un terminal.
[^] # Re: Installation des paquets et des dépendances
Posté par mgoeminne (site web personnel) . Évalué à 1.
Pour ce qui est de suivre l'évolution de l'installation, je ne vois pas le problème : on continue à avoir des paquets à installer, des paquets installés, et des paquets en cours d'installation. Selon mon approche, ce qui pourrait changer c'est que des paquets peuvent être téléchargés pendant que d'autres sont installés. Cette partie peut être plus difficile à représenter en console (pas avec des jauges, quoi). Mais au pire on peut toujours avec un pourcentage de paquets installés, et "oublier" de représenter le téléchargement des paquets qui se fait en arrière-plan.
Le problème de l'utilisation du disque dur me semble plus complexe. Mais dans mon cas (qui n'est sûrement pas une généralité, mais qui touche encore pas mal de monde je pense), le goulot d'étranglement n'est pas tant au niveau de l'écriture sur disque que la bande passante : dans mon cas, je vois la barre de progression des téléchargements avancer à vitesse de tortue, puis l'installation proprement dite s'exécute en un éclair.
Je me dis souvent que l'installation de la plupart des paquets déjà téléchargés aurait pu se faire 6-7 fois le temps que le téléchargement soit tout à fait terminé.
[^] # Re: Installation des paquets et des dépendances
Posté par Naha (site web personnel) . Évalué à 5.
[^] # Re: Installation des paquets et des dépendances
Posté par Changaco (site web personnel) . Évalué à 1.
Si les anciennes versions ne sont pas en cache on peut imaginer de créer ce cache de sauvegarde avant de commencer la mise à jour mais au final ça risque de ne pas valoir le coup, à part si la mise à jour concerne 200 paquets et qu'un seul n'est pas en cache.
[^] # Re: Installation des paquets et des dépendances
Posté par shbrol . Évalué à 1.
Et donc tu voudrais faire une partie de l'installation pendant le téléchargement, histoire d'améliorer les choses... Si tu arrivait à paralléliser complètement, alors le temps total de l'opération (tortue) serait le temps de téléchargement uniquement, puisque l'installation est plus rapide (éclair). Au final, tu ne gagneras presque rien, tu auras toujours une vitesse de tortue.
Tu as dit toi-même que le goulot d'étranglement c'est la bande passante de téléchargement. Si tu veux vraiment améliorer les choses, c'est là qu'il faut intervenir, pas sur le traitement suivant qui ne prend qu'une partie négligeable du temps total.
Je me dis souvent que l'installation de la plupart des paquets déjà téléchargés aurait pu se faire 6-7 fois le temps que le téléchargement soit tout à fait terminé.
CQFD.
[^] # Re: Installation des paquets et des dépendances
Posté par Naha (site web personnel) . Évalué à 1.
[^] # Re: Installation des paquets et des dépendances
Posté par steckdenis (site web personnel) . Évalué à 4.
Ça existe, il y a déjà pas mal de monde qui y a pensé. Le gestionnaire de paquets, Setup, que je développe, en est au moins un qui fonctionne comme cela.
Il télécharge les paquets et les installe en même temps, sachant qu'on peut également télécharger plusieurs paquets en même temps et en installer plusieurs en même temps.
Pour copier des fichiers, pas besoin d'avoir les dépendances déjà installées. Le seul problème est qu'un paquet peut vouloir modifier une de ses dépendances (mais ça pue, par exemple, on n'écrit pas dans /etc/X11/xorg.conf, on ajoute un fichier dans /etc/X11/xorg.conf.d. Plus de problèmes).
Pour cela, il y a les triggers, qui sont des scripts lancés séquentiellement une fois tous les paquets installés. Par contre, l'ordre des triggers les uns par rapport aux autres n'est pas assuré. Là, des modifications globales sont permises, comme un ldconfig, etc.
Les scripts de postinst et preinst sont eux exécuté juste après l'installation du paquet, par un processus Bash lancé par le thread qui installe le paquet. Ce script ne peut toucher qu'au paquet en cours d'installation (envoi de communications, un système à la debconf mais en mieux intégré, configuration en fonction de l'ordinateur sur lequel le paquet est installé (architecture, paramètres réseau), etc).
Et en effet, ça aide vraiment. Je bootstrap Logram en moins d'une minute, en installant build-essential (qui ramène logram-minimal-core). C'est un système qui ne démarre pas, mais qui contient Bash, les binutils, util-linux-ng, xz, tar, bzip2, less, sed, grep, etc.
Une petite visite de mon site perso, en particulier cette page : http://logram-project.org/packages-4-1.html , te montrera ce que contient ce paquet. Le site en lui-même présente Setup. J'ai également des journaux qui en parlent ainsi qu'une dépêche.
Voilà, j'ai assez fait ma pub.
[^] # Re: Installation des paquets et des dépendances
Posté par CrEv (site web personnel) . Évalué à 2.
Ce que je veux dire par là, c'est que je ne comprend pas _du tout_ comment ton gestionnaire fonctionne s'il n'est pas capable d'installer les paquets dans l'ordre... (à moins de faire des tests ds des cas particuliers uniquement)
[^] # Re: Installation des paquets et des dépendances
Posté par steckdenis (site web personnel) . Évalué à 2.
En fait, j'ai prévu le machin pour fonctionner dans 98% des cas, et être très rapide. Les 2% des cas restant peuvent soit être contournés (/etc/nginx/conf.d à la place de /etc/nginx/nginx.conf, etc), soit on adapte le solveur.
Par exemple, on sait qu'on va installer disons 2 paquets à la fois. Si le paquet nginx-mod-smtp pré-dépend de nginx, alors la liste des paquets installés (PackageList pour ceux qui lisent le code, ça se trouve sur Gitorious.org, projet "logram") va ordonner les paquets pour s'assurer que nginx sera au moins deux positions avant dans la liste par rapport à nginx-mod-smtp.
Ainsi, ce dernier paquet sait que nginx est d'office installé, et peut fonctionner :) .
[^] # Re: Installation des paquets et des dépendances
Posté par CrEv (site web personnel) . Évalué à 3.
je passe sur le 98%, c'est juste une mauvais solution à mon avis de raisonner comme ça pour ce genre de problème.
Pour l'histoire des 2 paquets, comment tu fais si je demande d'installer nginx et nginx-mod-smtp sachant que toutes les autres dépendances sont ok ?
Et surtout, pourquoi ne pas, simplement, installer les paquets dans l'ordre en permettant de paralléliser ce qui est possible, ie non mutuellement dépendant ?
Alors c'est sur, c'est tout de suite beaucoup plus complexe, mais maintenant je commence à comprendre comment tu as pu écrire un gestionnaire de paquet si rapidement, c'est juste qu'il n'est pas encore réellement capable et propre.
Dépendre de l'ordre de téléchargement pour installer est à mon avis assez mauvais et surtout pas beau du tout.
(note : spa maichant hein, mais quitte à vouloir faire un truc et à balancer du code, autant le réfléchir et pas se faire trop avoir ...)
[^] # Re: Installation des paquets et des dépendances
Posté par steckdenis (site web personnel) . Évalué à 2.
Si tu veux installer nginx et nginx-mod-smtp, et qu'il n'y a pas d'autres paquets, il faut alors attendre que le premier soit fini, c'est à dire n'installer qu'un paquet à la fois. La partie du code qui ordonnera les paquets détectera ça et abaissera automatiquement les installations en parallèle (et pour ceux qui diraient «oui mais alors, ça ralenti également le reste de la liste», ben s'il y a d'autres paquets dans la liste, le problème ne se pose pas, donc on ne réduit rien du tout).
Cette partie du code sera tout un optimiseur, qui remplira grosso-modo les fonctions suivantes :
* S'arranger pour regrouper les paquets qui proviennent d'un CD ensemble, pour éviter les Insérez le CD 1, Insérez le CD 2, Insérez le CD 1, etc
* Mélanger le plus possible les paquets des autres dépôts, pour pouvoir télécharger depuis autant de serveurs que possible si on DL beaucoup de paquets à la fois
* Commencer la liste par N (où N est le nombre de DL en parallèle) gros paquets sur des dépôts différents, de préférence, puis placer tous ceux venant des CD. Ainsi, pendant le téléchargement, l'utilisateur peut s'amuser à rentrer les CD
* Mettre les dépôts lents au début, les gros fichiers au début, pour éviter que le téléchargement se passe en 10 seconde puis qu'on attente 2h qu'un paquet de 300Mio soit DL depuis un serveur lent
* Encore quelques détails pour les CD en prenant éventuellement en compte le temps de seek du CD (classer les paquets par ordre alphabétique, sachant que c'est dans cet ordre (plus ou moins) que mkisofs les place sur le CD, mais là je ne suis pas sûr).
* Correction des problèmes cités plus haut : gérer les predepends.
Le but de la manoeuvre est de tirer le maximum de tout ce qui tourne autour de l'installation. Maintenir la liste des paquets téléchargés mais pas encore installés la plus importante possible, pour que l'installation aille au maximum de ce que l'ordi permet. Les différents dépôts et mirroirs doivent être les plus utilisés possible, en même temps. Quand aux CD, c'est une question de confort que de ne pas avoir à constamment changer de CD. Et comme je compte à un moment où à un autre distribuer Logram sur CD (+DVD ou quelques CD pour le dépôt), il faut que ce soit bien géré.
Ah oui, il faut aussi optimiser l'accès aux fichiers locaux. Ceux-là, comme ils sont quasiment instantanés, on les met entre les gros DL du début et les premiers CD. Ainsi, on peut commencer à installer très rapidement, pendant qu'on lit des CD et qu'on DL.
Toute une science. Je sens que je vais passez des jours à ce que ça marche bien :) (mais quand ce sera fait, ce sera une des killer-features de Setup).
[^] # Re: Installation des paquets et des dépendances
Posté par Guillaume Chanaud (site web personnel) . Évalué à 2.
C'est du prefetch, il dl le premier paquet, lance le build, et pendant ce temps continue à dl les autres paquets... Après c'est une distrib 'source', c'est peut-être moins facilement appliquable à une distrib binaire (mais j'en doute). J'ai trouvé l'option assez utile, car, de base, emerge télécharge le paquet, le construit, l'installe, puis fait la même chose pour le second paquet etc. etc. (contrairement aux 'autres' gestionnaires de paquets qui téléchargent tout, puis installent tout) Ainsi il est rapidement énervant de voir que le temps de la construction du paquet X qui vient de prendre 15minutes n'a même pas servi à pre-télécharger le paquet suivant qui fait 150Mo (genre open-office)
[^] # Re: Installation des paquets et des dépendances
Posté par Spack . Évalué à 1.
[^] # Re: Installation des paquets et des dépendances
Posté par Linschn . Évalué à 2.
Je pense que cette fonctionnalité a été développé dans Sorcery et dans Portage car le temps d'attente est centuplé par la nécessité de compiler les paquets.
# et packagekit
Posté par dufour olivier . Évalué à 5.
Ca pourait pas être un prolongement de projet packagekit qui tends a uniformiser la couche d'au dessus.
# Pour rappel et article
Posté par Foxy (site web personnel) . Évalué à 5.
Sur le site de Mancoosi, on peut trouver pas mal d'articles de recherches sur la complexité de la gestion des dépendances logicielles.
Je recommande particulièrement la lecture du papier "Strong Dependencies between Software Components" [http://www.mancoosi.org/papers/esem-2009.pdf] qui présente les dépendances des packages de la distribution Debian (avec plein de théorie des graphes de ands ;) ).
[^] # Re: Pour rappel et article
Posté par Spyhawk . Évalué à 1.
http://en.opensuse.org/Libzypp/Package_Management#References
# Moi, j'ai la meilleure gestion des des dépendances au monde...
Posté par FreeB5D . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.