«C'est la librairie avec son numéro de version qui définie la compatibilité et pas autre chose.»
T'as pas dû souvent en écrire des spec de pacquets toi.
«Tout ce qui compte, c'est la facilité réellement fournie et non le nom du paquet.»
J'aurai dis «et non le nom du truc dont on dépend». Ce qui sous Gentoo correspond par définition à la notion de paquet virtuel (genre si on a besoin d'un driver alsa ("virtual/alsa"), on peut se satisfaire soit d'un kernel 2.5/6, soit du driver pour les 2.4).
«L'héritage est aussi utile car il permet de limiter les nombres de dépendances et ne pas tomber dans l'ingérable.»
Je ne vois pas ce que tu veux dire, mais si c'est juste que si "A dépend de B et C" mais que "B dépend aussi de C" alors on peut se contenter de dire que "A dépend de B" (enfin bref pas lister systématiquement tout jusqu'à la glibc), et que ça qu'est génial c'est qu'on peut dire "installe A" et qu'il t'installera les trois, bah c'est pas vraiment un scoop, et je connais pas de système de paquets qui gère pas au moins ça. (Enfin si, je sais plus si rpm le fait, ou le faisais à une époque lointaine en tout cas, ou si c'est urpmi qui le rajoute).
«Rpm peut aussi définir des dépendances virtuels (style require: kde)»
Je sais pas dans le monde .rpm, mais dans le monde .deb c'était plutôt ce qu'on appelait des meta-paquets. Rien à voir avec la notion de paquet virtuel sus-citée.
«des dépendances sur des fichiers»
on en reviens au bon vieux nom/emplacements bien connus. Franchement, je préfère de loin l'abstraction des virtuals (tu fait comment avec un nom de fichier pour dire: un codec divx ?)
«tes fichiers de configuration seront conservés»
Bah manquerai plus que l'install d'un paquet t'écrase ta config existante? Sérieux, c'est encore vraiment la base. (Et la je commence à flipper en me disant que si tu nous les fait tous comme ça je suis pas couché.)
«En fait le système de génération des dépendances utilise des plugins et rien ne t'empêche de devopper de nouveaux plugins»
"inherit plugin" dans un ebuild (Ah nan merde, ça concerne pas que les dépendances mais ça permet de surcharger n'importe quelle methode et d'en définir de nouvelles utilitaires...)
«par exemple sur les symboles fournis par le noyau pour vérifier si un module noyau peut-être installé et marchera»
Faut vraiment être sur une distrib à binaire pour voir ça. C'est merveilleux tellement c'est aller loin contre le bon sens et la simplicité.
«T'as un gnome-2.2.2 spécifique qui utilise un libgnome-2.2.2 spécifique incompatible avec la branche 2.2, si un gnome-2.2.3 "standard" sort, il n'écrasera pas ta version spécifique mais un gnome-2.2.3 avec tes spécificités (marqués par le tag Epoch) sera un candidat pour la mise à jours.»
Cool, ça vous fait un USE flag. Aller, encore un petit effort, c'est presque ça. Mais gaffe à l'explosion combinatoire: 2^(nbre de USE flags) est exponentiel en le nombre de USE flags. Ça va en faire des versions spécifiques à compiler pour RedHat.
«rpm gére aussi les mises à jours sur plusieurs paquets et non seulement sur un seul.»
Ouahouuu!
«Rpm gère les paquets absolètes.»
Pur narcissisme.
«J'en suis sûre. »
Moi je suis sûr grâce à ton post que bientôt rpm aura rattrapé son retard sur apt. Encore qlqs amélioration (vrais paquets virtuels, héritage entre specs, gestion explicite des masques de paquets, mélange aisé de 3 niveaux de stabilité des paquets, système de merge des fichiers de conf, etc), et il sera au niveau de portage pour ce sur quoi il est raisonnable de les comparer. Mais il n'approche qu'à peine (et c'est bien normal, mauvais choix, mauvais résultats) la souplesse que peut offrir un système basé sur les sources (use flags, optimisation, drivers, etc.). Et je n'ai pas parlé d'un autre avantage des ebuilds: le système est tellement simple, et la nécéssité de compiler étant de toute façon là, qu'il devient très vite naturel de modifier un peu l'existant à sa sauce, de se faire ses propres révision bumps, d'écrire des ebuilds nouveaux plutôt que de make installer dans /usr/local, etc. De ce que je vois sur le forum, ou je passe un peu de temps, le "PORTAGE_OVERLAY", c'est à dire ton repository d'ebuilds persos, est une chose connue et utilisée par la quasi totalité des utilisateurs, au moins ponctuellement. Alors que franchement, sur une distrib à la redhat, c'est quoi la proportion d'utilisateurs qui ont un jour fait leur propre srpm ?
[^] # Re: Test de la Gentoo 1.4
Posté par tgl . En réponse à la dépêche Test de la Gentoo 1.4. Évalué à 3.
T'as pas dû souvent en écrire des spec de pacquets toi.
«Tout ce qui compte, c'est la facilité réellement fournie et non le nom du paquet.»
J'aurai dis «et non le nom du truc dont on dépend». Ce qui sous Gentoo correspond par définition à la notion de paquet virtuel (genre si on a besoin d'un driver alsa ("virtual/alsa"), on peut se satisfaire soit d'un kernel 2.5/6, soit du driver pour les 2.4).
«L'héritage est aussi utile car il permet de limiter les nombres de dépendances et ne pas tomber dans l'ingérable.»
Je ne vois pas ce que tu veux dire, mais si c'est juste que si "A dépend de B et C" mais que "B dépend aussi de C" alors on peut se contenter de dire que "A dépend de B" (enfin bref pas lister systématiquement tout jusqu'à la glibc), et que ça qu'est génial c'est qu'on peut dire "installe A" et qu'il t'installera les trois, bah c'est pas vraiment un scoop, et je connais pas de système de paquets qui gère pas au moins ça. (Enfin si, je sais plus si rpm le fait, ou le faisais à une époque lointaine en tout cas, ou si c'est urpmi qui le rajoute).
«Rpm peut aussi définir des dépendances virtuels (style require: kde)»
Je sais pas dans le monde .rpm, mais dans le monde .deb c'était plutôt ce qu'on appelait des meta-paquets. Rien à voir avec la notion de paquet virtuel sus-citée.
«des dépendances sur des fichiers»
on en reviens au bon vieux nom/emplacements bien connus. Franchement, je préfère de loin l'abstraction des virtuals (tu fait comment avec un nom de fichier pour dire: un codec divx ?)
«tes fichiers de configuration seront conservés»
Bah manquerai plus que l'install d'un paquet t'écrase ta config existante? Sérieux, c'est encore vraiment la base. (Et la je commence à flipper en me disant que si tu nous les fait tous comme ça je suis pas couché.)
«En fait le système de génération des dépendances utilise des plugins et rien ne t'empêche de devopper de nouveaux plugins»
"inherit plugin" dans un ebuild (Ah nan merde, ça concerne pas que les dépendances mais ça permet de surcharger n'importe quelle methode et d'en définir de nouvelles utilitaires...)
«par exemple sur les symboles fournis par le noyau pour vérifier si un module noyau peut-être installé et marchera»
Faut vraiment être sur une distrib à binaire pour voir ça. C'est merveilleux tellement c'est aller loin contre le bon sens et la simplicité.
«T'as un gnome-2.2.2 spécifique qui utilise un libgnome-2.2.2 spécifique incompatible avec la branche 2.2, si un gnome-2.2.3 "standard" sort, il n'écrasera pas ta version spécifique mais un gnome-2.2.3 avec tes spécificités (marqués par le tag Epoch) sera un candidat pour la mise à jours.»
Cool, ça vous fait un USE flag. Aller, encore un petit effort, c'est presque ça. Mais gaffe à l'explosion combinatoire: 2^(nbre de USE flags) est exponentiel en le nombre de USE flags. Ça va en faire des versions spécifiques à compiler pour RedHat.
«rpm gére aussi les mises à jours sur plusieurs paquets et non seulement sur un seul.»
Ouahouuu!
«Rpm gère les paquets absolètes.»
Pur narcissisme.
«J'en suis sûre. »
Moi je suis sûr grâce à ton post que bientôt rpm aura rattrapé son retard sur apt. Encore qlqs amélioration (vrais paquets virtuels, héritage entre specs, gestion explicite des masques de paquets, mélange aisé de 3 niveaux de stabilité des paquets, système de merge des fichiers de conf, etc), et il sera au niveau de portage pour ce sur quoi il est raisonnable de les comparer. Mais il n'approche qu'à peine (et c'est bien normal, mauvais choix, mauvais résultats) la souplesse que peut offrir un système basé sur les sources (use flags, optimisation, drivers, etc.). Et je n'ai pas parlé d'un autre avantage des ebuilds: le système est tellement simple, et la nécéssité de compiler étant de toute façon là, qu'il devient très vite naturel de modifier un peu l'existant à sa sauce, de se faire ses propres révision bumps, d'écrire des ebuilds nouveaux plutôt que de make installer dans /usr/local, etc. De ce que je vois sur le forum, ou je passe un peu de temps, le "PORTAGE_OVERLAY", c'est à dire ton repository d'ebuilds persos, est une chose connue et utilisée par la quasi totalité des utilisateurs, au moins ponctuellement. Alors que franchement, sur une distrib à la redhat, c'est quoi la proportion d'utilisateurs qui ont un jour fait leur propre srpm ?