J'ai hésité avant de faire ce journal.
Mais je pense que l'avis d'une personne, convaincu par les distributions binaires, sur une distribution source peut intéresser d'autres personnes.
Une personne convaincue par les distributions sources, sera convaincue par Gentoo et ce n'est "pas très intéressant" :-)
En général, je me fais exploser quand je teste un truc.
Je ne dois pas mettre assez de "la distribution de l'avenir", "un potentiel infini", ... et d'autres "formules" magiques.
Si vous vous attendez à des "formules" de ce type, allez vite ailleurs. Merci.
Pourquoi j'ai tester une Gentoo ?
Simple, j'ai voulu faire le point dans les distributions pour voir si ma distribution habituelle était la bonne (pour moi).
J'ai déjà testé Mandrake, Debian, Ubuntu (à l'arrache) et SuSE. Ma distribution habituelle est Fedora.
Donc, logiquement Gentoo est une suite dans cette série.
Sauf que Gentoo est une distribution source et c'est un modèle qui ne m'emballe pas. Il faut compiler, ça prend des plombes, ça bouffe de la place, si ça plante au milieu car t'as mis à jours une autre paquet t'as les boulles graves, si tu tombes sur une mise à jour d'un gros paquet en fait tu l'auras que 12 heures après (faut compiler), etc...
M'enfin, je me force car j'ai lu du bien de la distribution et aussi dans l'espoir de mourir moins con...
Ce test c'est déroulé il y a une semaine. Je dis tout de mémoire. Il y a peut-être des conneries.
Tout commence en allant sur le site Gentoo, je trouve la doc, elle est en français, elle n'est pas longue et correctement organisée. Surtout la doc évite de parler de ce qui n'est pas nécessaire. T'as le manuel d'installation (précis, concis) et pas un manuel d'installation noyé dans un manuel d'administration et d'introduction à Unix avec l'historique du mouvement open source dans le détail.
Bref, ça commence très bien. Une telle distribution dont le *coeur* de cible est les utilisateurs qui veulent un OS aux petits oignons doit s'appuyer sur une bonne doc et une bonne doc n'est pas un roman. C'est le cas. Le manuel d'installation est plus un HOWTO qu'un réel manuel. Pour une installation, c'est nickel. Le manuel d'utilisation ... est un manuel d'utilisation de Gentoo (c-à-d emerge/portage); et pas du logiciel libre en général. Tant mieux, c'est bien foutu.
Seul petit regrêt, le manuel passe rapidement sur l'installation depuis une installation existante alors que ça me semble la meilleur méthode, surtout car la plus confortable. Ton OS quotidien/favoris est disponible et en tâche de fond tu compiles.
En lisant la doc, ce qui m'a le plus particulièrement intéressé, c'est la capacité d'avoir une distribution "pil poid" correspond à mes besoins. Les optimisations de la mort qui tue avec CFLAGS, je m'en fous.
Pour un maximum de souplesse, il faut faire une installation depuis stage1. Je bootstrap. C'est long mais pas tant que ça.
Puis vient la configuration avant de compiler les programmes de mon choix.
Gentoo, donne une souplesse dans la configuration de la distribution assez impressionnante :
- USE : défini les fonctionnalités que vous voulez ou pas. Attention, ne définit pas les paquets que vous voulez ! Sert par exemple à dire d'ajouter le support pour postgresql aux programmes qui l'offrent. Par exemple, s'il y a "postgres" dans USE alors si vous demandez le paquet php, il sera compilé avec support pour postgresql.
- KEYWORDS : Agit comme un "filtre". Permet de choisir entre la branche stable ou de développement par exemple. Interdit aussi l'installation d'un paquet. Par exemple vous avez choisi la "branche" stable et demandez un programme classé dans "testing" alors l'installation du paquet sera refusée.
Il y a aussi les profiles. Par défaut, c'est gentoo-2004.2. Mais avec noyau 2.4. Étant déjà trop habitué à Linux 2.6, j'ai fouillé pour contourner ce point "faible" et découvert que portage supportait les profiles en cascade. Très astucieux ça (ça a l'air récent).
Donc dans le profile gentoo-2004.2 j'ai choisi gcc34 (en fait, pour KEYWORDS = "x86" (stable) c'est gcc 3.3).
Dans ce sous profile il y a Linux 2.6. Parfait, j'ai le bon profile :-)
Après, je fixe la variable USE. C'est assez long à faire et demande réflexion (une erreur peut coûter une longue recompilation). Au final, j'ai une variable USE longue comme un jour sans pain (nptl, python, pam, etc). Cyniquement, je me dis qu'avec tout ça la "fameuse" gentoo va se gauffrer comme une merde. Je n'ai pas cherché un truc tordu pour planté Gentoo ! J'ai honnètement choisi ce qui me convient.
La variable USE (dans /etc/make.conf) étant pour tous les paquets, il est aussi possible de définir la variable USE à utiliser par paquet. Je n'ai pas eu besoin de cette possibilité.
Donc, je choisi les fonctionnalités que je veux (variable USE), dans la "branche" stable (KEYWORDS="x86") dans un profile avec linux 2.6.
Il manque maintenant à choisir les paquets. Celà sera fait avec "emerge nom_paquet".
Le moins qu'on puisse dire, c'est que c'est particulièrement souple _et_ puissant (c-à-d parfaitement gèrable).
Par précaution (car le bootstrap c'est fait avec les entêtes linux 2.4 et sans NPTL), je mets à jours (+linux26-headers +gentoo-dev-source (linux-2.6)), compiles un noyau, et recompiles tous les paquets (emerge --emptytree world).
Tous se passe bien mais je me rend compte qu'il y a quelques dépendances circulaires (entre autre entre nptl/db4/libc, c'est indépendant de Gentoo).
Bon, j'emploi les gros moyens. Je passe à stage2 (emerge system) et recompile encore le tout (emerge --emptytree world).
C'est long....
Mais ça ne me dérange pas. Je fais ça en chroot (+ screen) depuis ma distribution "normale" que je peux utiliser pleinement comme d'habitude.
C'est long ... mais c'est bon. Tout est d'équerre. Un petit "ooops", j'ai du ajouter "posix" pour perl.
Notons que je fais ça depuis FC3T3 et que chroot n'a pas posé de problème contrairement à Debian et Ubuntu.
Avant d'attaquer le "gros" reste (la compilation des programmes de mon choix), je fais quelques "emerge --verbose --pretend paquet" pour voir ce qui m'attend. À vu de pif, tout est correcte. Les dépendances sont pertinentes et je n'ai pas à ajouter de trucs (par contre, parfois, certaines dépendances semblent inutiles). Dans les paquets, il y a des paquets "virtuels" comme le paquet gnome. Par exemple "emerge gnome" signifie pour ma configuration : installe Gnome (les paquets "réels" et stables qui vont biens), demmerde toi avec les dépendances en tenant compte de la variable USE que j'ai défini.
Je lance "emerge postgresql subversion php x11 gnome evolution openoffice-xiniam pan ..." et je vais me coucher avec l'assurance de voir un joli plantage le lendemain matin compte tenu de mon USE.
Une petit explication sur "emerge 'paquet'". C'est un peu plus subtile qu'un "apt/yum install 'paquet'" avec la compilation en plus.
Les emerges explicitent (qui ne sont pas liés à une dépendance) sont stockés dans "world". World indique uniquement les paquets que vous avez explicitement demandés et donc dont que vous avez explicitement besoin. Ainsi, si après une mise à jours, un paquet n'a plus de dépendance avec world, vous (en réalité emerge/portage) pouvez facilement le savoir et le supprimer. Celà se fait avec "emerge depclean". Un "emerge --pretend depclean" ("--pretend" liste ce qui va être fait) est conseillé néanmoins :-).
Ou en étions nous ? Ah oui, je suis allez me coucher après avoir lancé un énorme "emerge ...." et me suis préparé psychologiquement à voir un plantage le lendemain matin. Le lendemain matin au réveil, je vais en direction de mon PC le sourire en coin.
Énorme déception. Ça compile toujours "joyeusement".
Je regarde le log de la compilation et je vois quelques "warning, lancer etc-update".
J'arrêtes la compilation (^C) et m'exécute. etc-update est assez trivial/basic mais astucieux et bien vu. Il permet de fusionner les fichiers de configurations actuels avec les nouveaux fichiers proposés. C'est un outil merge classique comme avec les gestionnaires de version. Je ne vois rien de "grave" et tout (deux fichiers :-)) est fusionné "les doigts dans le nez".
Je relance la même longue commande emerge (moins ce qui a déjà été fait) en me disant que c'est un bon test pour voir comment emerge va reprendre son travail. Ça roule sans problème.
Gentoo a aussi des "fonctionnalités" intéressantes que je n'ai pas testé. Il y a le flag "hardened" pour USE qui renforce la sécurité. SeLinux est aussi supporté et tout est configuré à la volé (comprendre avec une lonnngguuueee compilation). En fait, on trouve pratiquement tout.
Gentoo étant orienté source, on pourrait croire que c'est relativement "rustre" et que les paquets sont brutes de décoffrage. En fait non. Il y a beaucoup de "add-on", de patchs spécifiques.
De même, les fichiers de configurations par défaut sont globalement bien foutus et ce n'est pas le stricte minimum qui est fourni.
Enfin, la compilation est terminée. Dieu que c'est long. Je parcours l'énorme log et je constate qu'il reste quelques problèmes de dépendance circulaire. Mais Gentoo n'y est peut rien. J'ai autre chose à faire pour les deux jours à venir et pendant ce temps je peux refaire un "emerge --emptytree world". Je le fais.
Deux jours plus tard, tout est place. Je fais le tour du propriétaire :
- Linux 2.6.8.1 + patchs
- libc 2.3.3 assez récente
- evolution 1.4 (c'est la branche stable)
- firefox 0.10
- gnome 2.6
- xorg 6.8.0
etc...
Pour une version stable, c'est à jour.
Avant de rebooter sous Gentoo, il faut passer un bon moment avec la doc et les fichiers de configurations dans /etc. Rien de très dure mais assez long.
Je paufine /etc, me crée un compte, et je vérifie une dernière fois.
Tout est OK, je reboote.
Je suis sous Gentoo. Que dire ? Ça marche. À partir de là, c'est une distribution "comme les autres". Son "charme" n'est pas là. Du coup j'ai plus envis de jouer avec elle ;-|
Pour le "fun", je fais :
- emerge --sync
- emerge --deep update
Fichtre. Il y a une mise à jours d'openoffice....
^C
Je vais finir sur un reproche. Il manque un "journal" des compilations avec les warnings/conseils donnés par emerge. Fouiller dans les logs (qu'on aura pris soit de créer...) est lourd.
Conclusion:
Je ne parle que de l'emploi "stage1" (ou stage2, il n'y a pas énormément d'écart) ou on peut réellement tirer avantage de la formidable souplesse de Gentoo par rapport aux autres distributions.
Je ne change pas de distribution et reste un adèpte des distributions binaires (avec les sources de disponibles qu'en même :-)).
Néanmoins, force est de constater que Gentoo est particuliairement bien foutu. L'installation est "laborieuse" mais un usage quotidien semble tout à fait envisable avec la branche "stable" même adaptée aux petits oignons comme je l'ai fait. Il n'y a qu'à faire "emerge --sync ; emerge --update" de temps en temps et suveiller le log de les compilations.
Il ne faut pas si tromper, même si je ne passe pas sous Gentoo, cette distribution, pardon, cette meta-distribution m'a _réellement_ impressionnée. Elle m'a impressionné par ces idées/inovations et par la qualité globale compte tenu des contraites énormes : faire une (meta)distribution source _hyper_ configurable, _réellement_ gérable et stable.
Chapeau bas.
Et en plus ça marche sur plusieurs plate-forme. Que dire de plus ? Les faits parlent d'eux même.
Il est vrai que j'ai du mal à voir l'intérêt _réel_ de tout ça. Peut-être pour l'embarqué ou quelques cas particuliers. Quoiqu'il en soit, c'est une formidable bête à compiler et une plate-forme de test du logiciel libre (compiler dans 50 000 configurations différentes) formidables. C'est peut-être grace ça qu'elle est déjà disponible sur plusieurs plate-forme et très à jours.
Bref, gouttez la et si le coeur vous en dit bouffez en tout les jours :-) (surtout si vous avez un gros apétit (genre bi-cpu ou quadri-cpu)).
Bien que l'installation ne soit pas très dure (mais très loins d'être "out of box"), elle demande un minimum de background et surtout de culture du logiciel libre. Sinon on n'est pas capable de définir correctement ce qu'on veut (variable USE) et Gentoo (depuis stage1) est sans intérêt.
Par rapport à la série de distribution que j'ai testé, Gentoo a amené de la fraicheur. Elle a du "chien" par rapport aux autres. C'est aussi la dernière distribution que je teste et je suis content de terminer sur Gentoo et non sur une ennuyeuse ... ou ...
Journal [Long] Expérience Gentoo
23
oct.
2004
# En ce qui me concerne.
Posté par farib . Évalué à 5.
L'impression que j'ai eu, c'est que le moindre USE flag va avoir des conséquences monstrueuses sur tout l'arbre de dépendances, alors qu'on ferait peut-être une meilleure utilisation des USE flags au niveau des dépendances en les spécifiant uniquement sur la ligne de commande.
(Ca n'est qu'une impression)
[^] # Re: En ce qui me concerne.
Posté par 007 . Évalué à 2.
Tu peux spécifier le USE en ligne de commande avec Gentoo.
[^] # Re: En ce qui me concerne.
Posté par farib . Évalué à 2.
Par contre, sous free, lorsqu'on commence à compiler un port, y'a un petit message qui apparait tout de suite pour indiquer quelles seraient les DEFINE intéressants ( et utiles) à rajouter.
[^] # Re: En ce qui me concerne.
Posté par 007 . Évalué à 3.
> Par contre, sous free, lorsqu'on commence à compiler un port, y'a un petit message qui apparait tout de suite pour indiquer quelles seraient les DEFINE intéressants ( et utiles) à rajouter.
C'est clairement un domain où Gentoo peut s'améliorer.
Mais il y a aussi un outils pour ça dans Gentoo :-)
C'est etcat (voir en bas de la page) :
http://www.gentoo.org/doc/fr/handbook/handbook-x86.xml?part=2&c(...)
"emerge --pretend --verbose" donne une synthèse plus ramassé et avec les dépendances.
Il manque peut-être un outils centralisé pour "naviguer" rapidement dans portage et avoir une vue d'ensemble. Entre autre pour connaitre l'impact du changement de USE. Actuellement si USE (dans make.conf) est changé, il faut tout recompilé ou c'est à l'utilisateur de déterminer ce que va impacter le changement de USE et faire les "emerge ..." un par un.
Je dis ça, mais c'est ma première expérience avec un système type portage et je n'ai peut-être pas assez de recul.
# Expérience Gentoo
Posté par Yoann A. . Évalué à 5.
Le gros intéret de Gentoo, par rapport aux distributions binaires, est le catalogue de logiciels disponibles. Ajouter un paquet à portage est relativement simple et rapide, en tout cas plus que d'ajouter un paquet binaire. Du coup, il y a plus d'applications et ces applications sont aussi plus à jour.
Autres intérets, en vrac : communauté sympa, bonne doc, distribution très propre/carrée (notamment, j'aime beaucoup la gestion des applications web : http://www.gentoo.org/proj/en/glep/glep-0011.html(...))
Par contre :
- c'est long (comparé aux 20 minutes d'install d'Ubuntu, par exemple)
- ça prend plus de place sur le disque (deux fois plus en moyenne), notamment à cause de portage
- j'ai aussi trouvé que l'exécution est plus lente que les paquets pré-compilés pour Debian (c'est surtout sensible sur une petite machine : celeron 400)
> Chapeau bas.
Content de voir que tu n'es pas toujours négatif ;)
[^] # Re: Expérience Gentoo
Posté par 007 . Évalué à 5.
Mouaif... Il y a pleins de logiciels dans Debian, Fedora + extra, Mandrake + flp.
Je ne vais pas te contredire car il y a effectivement pléthore de logiciel et surtout de configurations (avec ou sans acl, selinux, etc). D'ailleur je me demande s'il n'y a pas plus de logiciel dans Gentoo que dans Debian.
Par contre, la "facilité" pour compiler permet d'avoir des paquets sources synchroniser avec l'évolution de la distribution et beaucoup testé. C'est un gros plus du moment qu'il y a suffisament d'utilisateurs qui est du coup aussi un testeur. S'il y a beaucoup d'utilisateurs, il y a moins de personnes qui tombent sur les bugs dû à l'évolution de la distribution et ça tient la route d'un point de vu utilisateur (qui n'a pas envis d'être principalement un testeur). Apparament, le nombre d'utilisateur est suffisant.
L'autre point faible des distributions binaires est qu'il faut souvent un binaire par version de distribution (FC1, FC2, etc...) et il faut un testeur "dédié" (au moins pour faire "manuellement" le paquet).
> Content de voir que tu n'es pas toujours négatif ;)
Je suis pas toujours négatif. Mais je suis parfois "affolé" par l'emballement de certains. A titre d'exemple, il y a Ubuntu qui est sorti pour la première foi et il y déjà il y a des "promis à un bel avenir" ...
Pour un "premier essai", c'est certe réussi, mais ça me sidère de lire "promis à un bel avenir". Ubuntu n'est pas la première dans ce registre (Xandros, Linspire). On manque furieusement de recul pour affirmer ça.
Les projets estampillé "de l'avenir" et qui sont dans les oubliettes ou n'ont jamais réellement décollés ne se compte plus :
http://www.xouvert.org/(...) : Il en est où ?
Yoper : C'est maintenant confidenciel
reiserfs : Il est là et bien là mais n'a pas mis au placard tous les autres FS comme affirmé au début
...
Il y a aussi l'inverse :
rpm puxor : n'empêche qu'il est là, très utilisé et c'est une belle pièce logiciel
ext3 c'est le FS des vieux : oui mais ...
Donc, j'ai tendance à être mesuré. Normalement, la moyenne de nos critiques doit aboutir à un "c'est moyen" et pas un "c'est génial". Sinon lorsqu'on entend "c'est génial", il faut comprendre "c'est moyen" et on ne sait pas quoi dire pour quelque chose de réellement génial.
Ici je dis "Chapeau bas" et il a toute sa signification. Ce n'est pas :
- en réalité c'est "moyen" mais je préfère dire "chapeau bas" pour montrer que je suis positif et pas un éternel grinceux.
[^] # Re: Expérience Gentoo
Posté par Ramso . Évalué à 1.
> déjà il y a des "promis à un bel avenir" ...
On avait dit la même chose de Fedora.
[^] # Re: Expérience Gentoo
Posté par 007 . Évalué à 1.
!!!
Où ?
Pour ton info, l'annonce de Fedora est là :
http://linuxfr.org/2003/09/22/14028.html(...)
Lis les commentaire.
Pour te montrer comme la "confiance" était légère :
http://linuxfr.org/2004/05/05/16176.html(...)
attendons de voir si cette décision aura un impact sur le sort de la "distribution communautaire"
On prédisait déjà presque la mort de Fedora...
[^] # Re: Expérience Gentoo
Posté par 007 . Évalué à 0.
Oh, il y a une rc1 de FC3 :
http://fedora.linux.duke.edu/FC3-rc1/3/(...)
Non, je ne vais pas dire qu'elle est géniale et qu'elle va atomiser tout le reste :-)
# Gentoo user
Posté par MsK` . Évalué à 1.
troll root # genlop -t openoffice-ximian * app-office/openoffice-ximian Thu Sep 2 15:46:34 2004 --> app-office/openoffice-ximian-1.1.61 merge time: 8 hours, 23 minutes, and 56 seconds. Sat Oct 16 21:35:03 2004 --> app-office/openoffice-ximian-1.3.5-r1 merge time: 10 hours, 7 minutes, and 19 seconds. merged totally 2 ebuilds in 18 hours, 31 minutes, and 15 seconds. average merge time: 9 hours, 15 minutes, and 37 seconds.[^] # Re: Gentoo user
Posté par 007 . Évalué à 1.
Peut-être. Mais le but était d'avoir quelque chose de "carré".
Lorsque t'actives ntpl et que db4 est compilé avec "-pthread" c'est normal. Quand tu vois que la libc est compilé après, il y a comme un problème. Lorsque t'installe linux2.6 mais la libc a été faite avec les headers de linux 2.4, il y a encore un problème. Je jetes pas la pierre à Gentoo. C'est "normal". D'ailleur la _doc_ dit qu'il faut tout recompiler lorsqu'on change USE pour être _sûre_ du résultat.
Comme j'ai dis, une fois que tout est en place, il n'y que d'a faire des "emerge --sync ; emerge --deep --update" et plus de "emerge --emptytree".
> genlop Exemple au hasard
> merge time: 8 hours, 23 minutes, and 56 seconds.
Je m'en fous de ça :-)
Je veux les warnings/conseils. Lorsque j'ai installé Linux-2.6 il indique ce qu'il faut mettre dans grub.conf. C'est ce type d'info que je veux sans fouille dans un gigantesque fichier log.
# Qlqs compléments
Posté par tgl . Évalué à 5.
Quelques petit commentaires en vrac :
Tu ne parle pas du système d'init, je sais pas si tu t'es penché dessus, mais perso c'est un des trucs qui m'avait emballé au début. Pour faire court :
- l'ordre de démarrage des services n'est pas spécifié statiquement mais calculé en fonction de leurs besoins spécifiques (chaque script déclare des "need machin", "after truc", etc.). C'est joli et simple à utiliser. Cerise sur le gateau, ça a permis de facilement ajouter la parallélisation des démarrages de services il y a maintenant un bout de temps (ce qui n'a pas un grand intérêt, mais bon, pourquoi ne pas le faire puisqu'avec ce système c'était simple);
- on peut créer autant de runlevels qu'on veut, ce qui est bien pratique pour jongler dans les configs réseau par exemple, ou bien se faire un mode maintenance moins frustre que le single user, ou démarrer simplement l'ensemble des services dont on a besoin pour bidouiller son site web, etc. C'est vachement + souple que les 2 ou 3 niveaux d'init disponibles sur la plupart des distribs.
Tout ça en détails ici : http://www.gentoo.org/doc/fr/handbook/handbook-x86.xml?part=2&c(...)
Un autre point super important de la ditrib, c'est sa notion de "stabilité" qui est bien différente des distribs fonctionnant par releases globales. On a sous Gentoo des releases, certes, mais qui concernent uniquement les CD d'install, les stages, et les profiles. Les paquets par contre sont tous traités individuellement via leur KEYWORDS, avec au final une distrib "stable" en permanente évolution (et différente sur chaque archi). C'est vraiment une différence fondamentale avec la plupart des autres distribs. Bon, on aime ou on aime pas, on a confiance en ce système ou pas, ça c'est à chacun de voir, mais je crois que c'est vraiment un truc qui est décisif pour adopter ou non Gentoo.
Niveau points faibles, y'a un truc dont tu n'as probablement pas eu le temps de faire l'expérience, c'est que le système de dépendances sur les paquets sources est plus faible que ce qui se fait sur des binaires. Il représente ce qui est nécéssaire pour compiler, mais une fois le paquets compilé, il peut avoir des dépendances de runtime plus strictes (typiquement, un paquet nécéssitant "libtoto-1*" peut compiler sans pb avec libtoto-1.0 ou libtoto-1.1, mais une fois linké à libtoto-1.0.so, sa dépendance devient plus précise, et une mise à jour de libtoto en 1.1 pourra le casser). Ça c'est un truc que Gentoo ne prend pas bien en compte. Y'a bien un outil pour rebuilder les paquets qui se retrouvent cassés de cette façon, mais c'est vraiment pas une "solution". Y'a plusieurs approches possibles pour faire prendre ça en compte à portage, mais c'est une modif assez fondamentale, donc je sais pas si ça va venir de si tôt.
À propos d'etc-update, c'est vrai qu'il est assez frustre, mais il y a mieux : "dispatch-conf". Celui là rempli la même tâche, mais ajoute :
- un système de backup avec gestion de versions de tes fichiers de conf (basé sur RCS ou bien sur un gros paquet de "fichier.version", au choix),
- la mise à jour automatique des fichiers qui sont encore dans leur état par défaut
- une assistance au merge entre ta conf courante et le nouveau fichier par défaut, basé sur "diff3" (prenant en compte donc l'ancienne configuration par défaut pour identifier ce que tu as changé/ajouté et faire la même modif sur la nouvelle configuration par défaut)
Sur les infos qui se retrouvent perdus dans les logs de compil', c'est effectivement un pb, mais y'a pas mal de solutions. Y'a par exemple différents petits scripts qui vont parser les logs à leur recherche, genre ça :
http://tdegreni.free.fr/gentoo/portlog-info(...)
Y'a aussi des patchs pour emerge qui trainent avec des solutions diverses (rapporter les messages à la fin des compil, ou les mailer au root, ou cacher le dump de make, etc.). Par exemple :
<blink>pub</blink> http://bugs.gentoo.org/show_bug.cgi?id=37491(...)
En fait il serait vraiment temps que les mainteneurs de portage se décident pour une solution, parceque c'est une requête récurrente et justifiée.
Concernant le temps bouffé par les compilations, bof, faut voir, c'est pas forcement un problème. Bon perso ça me dérange carrément pas, c'est une tâche de fond qui remplace très bien un seti@home, et puis voilà. Mais même sans être aussi tolérant, on peut pas mal réduire la chose. Gentoo sort régulièrement des paquets binaires, qu'on peut utiliser pour faire une installation initiale rapide. C'est une assez bonne approche en fait : tu as très vite ta distrib utilisable, et après tu réinstalles from sourfces au fur et à mesure où les besoins s'en font sentir des paquets avec des USE flags personnalisés. Au bout de qlqs temps, tu as une distrib bien à toi, sans pour autant être jamais passé par la case grosse compil' de 48H.
Concernant «l'intérêt de la chose», bah... question de goût quoi. Moi j'aime bien, c'est une distrib qui est très souple mais pas inutilement compliquée pour autant, qui m'a toujours permis de faire tout ce que je voulais comme je le voulais sans grosse prise de tête.
[^] # Re: Qlqs compléments
Posté par 007 . Évalué à 3.
Non :-)
En général je veux que ça marche. La classique sysinit me convient. Même s'il est lent, il est "rock solid".
Néanmoins, il y a quelques belles idées qui germent du côté de Fedora (rien de concrête et aucun travaux engagé).
L'idée principale, est de passer par DBUS. Ainsi toute les phases d'initialisation sont connues et on peut "connecter la sortie" sur syslog (c'est un exemple) ou sur une barre de progressions, ou un système qui gère le parallélisme, etc...
Intéressant. Mais bon ce n'est pas ma "priorité".
Au-delà d'init, j'ai noté tous les petits add-ons spécifiques Gentoo (J'ai été très surpris de voir le nombre de patchs). Gentoo n'est pas qu'une distribution source. C'est une distribution qui a sont propre typage même si tu l'installes uniquement avec les binaires déjà compilés.
> Un autre point super important de la ditrib, c'est sa notion de "stabilité"
Oui. J'ai pas beaucoup insisté sur ça, mais ce qui m'a impressionné c'est la qualité de l'ensemble pour la branche "stable". Juger de la qualité en utilisant la branche testing n'est pas très pertinant :-)
> Les paquets par contre sont tous traités individuellement via leur KEYWORDS, avec au final une distrib "stable" en permanente évolution (et différente sur chaque archi).
J'ai bien noté ça. Par exemple, l'image stage1 qu'on récupère sur le site Gentoo sert uniquement pour le bootstrap. Contrairement à ce qu'indique la doc, j'ai mis à jours portage avant de faire le bootstrap. Après le bootstrap (qui s'appuie sur les infos de portage), je n'ai pas stage1 de Gentoo-2004 mais la dernière version de stage1 (stable dans mon cas). Donc, ce que j'ai fait après le bootstrap, n'est pas depuis une Gentoo-2004 mais depuis la dernière branche stable.
Si j'ai pris un profile "gentoo-2004" c'est car c'était le seul que j'ai vu avec KEYWORDS="x86" et linux 2.6 . J'ai bien vu "default-linux" (j'ai oublié le nom) mais je n'ai pas trouvé dedans de KEYWORDS="x86" et linux 2.6. Un expert ferait peut-être autrement.
> C'est vraiment une différence fondamentale avec la plupart des autres distribs.
Tout à fait. Notes que j'ai indiqué que j'avais xorg-x11 6.8.0, firefox ... "out of the box" dans la branche stable. xorg-x11 6.8.0 n'était pas dans Gentoo-2004 à la sortie.
Et Sunbird m'a été refusé car "pas stable". Normal.
> on a confiance en ce système ou pas
Ça dépend de la qualité du travail fait par les mainteneurs. Or, j'ai rien à reprocher :-)
> Niveau points faibles, y'a un truc dont tu n'as probablement pas eu le temps de faire l'expérience, c'est que le système de dépendances sur les paquets sources est plus faible que ce qui se fait sur des binaires.
En fait, j'ai vu ça :-)
Mais la distribution étant orienté source, c'est normal et donc je ne vais pas le lui reprocher. La distribution gére les dépendances uniquement au niveau source. C'est aussi pour ça que la seul façon fiable de prendre en compte une changement global de USE et de tout recompiler. Sinon il faut connaitre toutes les dépendances binaires.
> Y'a plusieurs approches possibles pour faire prendre ça en compte à portage, mais c'est une modif assez fondamentale, donc je sais pas si ça va venir de si tôt.
J'avais pensé à une phase intermédiaire. Ce qui est installé est (par exemple) géré par rpm (donc avec une base de donnée des dépences binaires de l'installation).
En gros, emerge fait un paquet type rpm (avec détection de version de librairie, etc) puis tente de l'installer. Si les dépendances binaires ne sont pas respectées, emerge donne un gros warning sur ce qui doit être mis à jour (qui dépend de libtoto-*). Notes que la détermination ne peut être faite qu'après la compilation de la nouvelle librairie.
C'est clairement un défaut des distributions orientés sources. Mais que faire...
Ça peut demander _beaucoup_ de recompilation et un système temporairement inutilisable (Les programmes dépendants de libtoto-* ne marchent plus tant qu'ils ne sont par recompilés). Il y aussi la possibilité d'avoir temporairement les deux librairies en même temps et de supprimer n'ancienne une fois que tout est mise à jours. Mais j'ai peur que certains paquets utilisent l'ancienne librairie même s'ils sont reconstruits avec la présence de la nouvelle librairie.
Pour le reste de ton post, tu montres que Gentoo est encore en pleine évolution.
Mais j'ai envi de dire un "truc" sur le préjugé :
- distribution binaire, distribution figé
Ceci faux. Ce n'est pas parce que la distribution est binaire qu'elle est figée. C'est uniquement une question de gestion de projet.
J'avais une FC2, j'ai mis à jours (avec rpm) vers FC3T1 et suivi toute l'évolution de rawhide. Sûr, ça "merde" parfois. Mais ça merde car c'est une branche de *développement*. Si ce n'était pas une branche de développement, Fedora ferait soigneusement attention à ce qu'ils ajoutent ou mettent à jour.
Fedora et Gentoo ne sont pas séparés uniquement car l'une est orienté source et l'autre binaire. Mais aussi dans une façon différente de gérer la distribution, le projet.
La méthode Gentoo a ses avantages ; on vient de les lister :-)
La méthode Fedora (et beaucoup d'autres) a ses avantages. FC3 (qui sort dans deux semaines) aura udev/hal en stable, Gnome 2.8 en stable, etc.
L'avantage de Fedora, est de pouvoir "tout casser" par moment pour avancer vite sans grosse prise de tête avec la compatibilité la fiabilité.
C'est la même chose avec les Linux de numéro impair.
[^] # Re: Qlqs compléments
Posté par tgl . Évalué à 3.
> même temps et de supprimer n'ancienne une fois que tout est
> mise à jours.
C'est en gros l'idée des approches les plus réalistes qui ont été proposées. En gros, on conserverait au fil des installation de paquets compilés un cache de dépendances de librairies. Lors d'une mise à jour libtoto-1.0->1.1, le libtoto-1.0.so ne serait supprimé que si il n'est plus référencé dans le cache. Sinon, il serait conservé et rajouté au contenu référencé par libtoto-1.1, pour être éventuellement nettoyé lors d'une future mise à jour 1.1->1.2 par exemple.
> Mais j'ai peur que certains paquets utilisent l'ancienne
> librairie même s'ils sont reconstruits avec la présence de la
> nouvelle librairie.
C'est un truc auquel il faudrait faire gaffe, mais ça peut être fixé par les ebuilds quand un paquet à tendance à se comporter comme ça, donc c'est pas vraiment bloquant.
Enfin bref, tout ça pour dire que ce problème est effectivement assez naturel sur une distrib source, mais qu'il y aurait moyen de le traiter quand même.
> Ce n'est pas parce que la distribution est binaire qu'elle est figée.
> C'est uniquement une question de gestion de projet.
Oui, je suis plutôt d'accord. Enfin avec un bémol : je pense que l'approche source, parceque justement les dépendances y sont un peu plus souples que celles des paquets binaires, facilite un peu le dynamisme au sein d'une branche stable. Avec des paquets binaires, à cause des dépendances de lib + strictes, tu as plus souvent à faire des commits groupés (typiquement, avec une lib, les programmes qui y sont linkés). Mais ça reste très envisageable, et je pense qu'il y a encore une place à prendre pour une distrib binaire qui ne serait pas orientée releases et qui ne serait pas pour autant une branche de développement. C'est peu être un peu le cas de debian testing, qui si j'ai bien compris passe quand même par une certaine dose de QA, même si elle n'est pas officiellement "stable" (enfin j'dis ça, je connais pas bien, je sais pas par exemple si ils s'imposent que testing soit égale sur toutes les archis ou si, comme gentoo, les différentes archis évoluent chacune à son rythme).
> L'avantage de Fedora, est de pouvoir "tout casser" par moment
> pour avancer vite sans grosse prise de tête avec la compatibilité
> la fiabilité.
> C'est la même chose avec les Linux de numéro impair.
En fait sous gentoo tu peux te permettre ça aussi sur un groupe d'ebuilds que tu hard-masques. Et une fois l'ensemble prêt, les paquets passent en ~arch avec des dépendances qui forcent l'update de l'ensemble tout d'un coup pour rester cohérent. Mais bon, ouais, c'est quand même un peu moins souple.
[^] # Re: Qlqs compléments
Posté par 007 . Évalué à 2.
Oui et non, mais non. C'est un problème de gestion de projet et pas de "contraintes techniques" spécifiques au distribution binaire.
Avec une distribution binaire classique, il y a une seule configuration et une seule possibilité => monté vers la dernière version, le dernier "snapshot". Ce qui compte c'est que la dernière version soit cohérente et que les scripts de mise à jours marchent. C'est tout.
Si tu n'as qu'un dépôt, il est trivial de garantir qu'il n'y aura pas de dépendances de cassés et que celui qui fait une mise à jour n'aura pas de problème (du moins avec les dépendances). En bricolant rapidement avec "rpm --justdb --noscripts ...." tu peux vérifier les dépendances pour plusieurs dépôt (par exemple Fedora Core + Fedora Extra + Fedora Extra non-US). De plus, il n'y a qu'un environnement de développement (paquet rpm *-devel) : le dernier c'est tout. Et non un environnement avec nptl, un autre avec python, l'autre sans, etc.
Ça c'est pour le côté "serveur". Celui qui fournit les logiciels. D'autres outils vont peut-être voir le jour avec le nouveau format de dépôt : http://linux.duke.edu/metadata(...)
Ce format a été adopté par FC3. FC va aussi adopté Mach qui s'occupera des dépendances sources (avec peut-être génération automatique des "BuildRequire", j'ai pas vérifié depuis longtemps mais mach est vraiment intéressant) et maintient l'environnement de développement.
Pour le côté client, si tu fais une mise à jours de FC1+Fextra1 vers FC3+Fextra3 (pour donner un exemple multi dépôt), avec yum/apt/update s'il y a des problèmes de dépendances l'installation de sera pas faite ! _Aucun_ paquet n'est mis à jour.
Impossible d'avoir quelque chose de cassé (côté dépendance) sans utiliser des méthodes brutales ("rpm --nodeps").
Là on voit un "big" problème pour Fedora. En effet, anaconda (l'installeur fedora) ne fait que FC1+Fextra1 vers FC3. Avec un peu de "skin" on peut fait ça avec yum.
Donc clairement, d'un point de vu technique, l'avantage est côté distribution binaire (+ un bon gestionnaire de paquet) pour avoir des mises à jours récentes (si on est pas à une semaine prêt évidemment). En fait, l'avantage est au distribution binaire mono-config :-)
La "tarre" de Gentoo sur ce point est d'être multi-config (c'est aussi son avantage).
L'avantage du source dans un contexte multi-config est ailleur il me semble. Je l'ai expliqué ici :
http://linuxfr.org/comments/488625,1.html(...)
Par contre, la "facilité" pour compiler permet d'avoir des paquets sources synchroniser avec l'évolution de la distribution et beaucoup testé. C'est un gros plus du moment qu'il y a suffisament d'utilisateurs qui est du coup aussi un testeur. S'il y a beaucoup d'utilisateurs, il y a moins de personnes qui tombent sur les bugs dû à l'évolution de la distribution et ça tient la route d'un point de vu utilisateur (qui n'a pas envis d'être principalement un testeur). Apparament, le nombre d'utilisateur est suffisant.
L'autre point faible des distributions binaires est qu'il faut souvent un binaire par version de distribution (FC1, FC2, etc...) et il faut un testeur "dédié" (au moins pour faire "manuellement" le paquet).
> tu as plus souvent à faire des commits groupés (typiquement, avec une lib, les programmes qui y sont linkés).
C'est un défaut et un avantage si tu y regardes de près. Tu montes en version que quand ça ne casse pas ton système.
> je pense qu'il y a encore une place à prendre pour une distrib binaire qui ne serait pas orientée releases et qui ne serait pas pour autant une branche de développement.
Peut-être, mais tu finis toujours par être bloqué ou être dépendant des capacités de mise à jours. Si Gnome 3.0 sort et n'est pas compatible avec Gnome 2.x et n'as pas de mise à jours automatique des données, c'est dur dur (surtout avec les données des utilisateurs (configuration)).
Il y a le même problème pour Apache 1.3 vers Apache 2.0, etc.
Je crois que la "bonne" voie (apréciation personnelle), la plus souple (développement) et existante (logiciel récent) est la politique des petits bons (par exemple FC2 -> FC3).
Si tu compares Gentoo stable maintenant avec FC2, FC2 est en retard mais de pas beaucoup (si j'était méchant, je dirais que FC2 à Linux 2.6 contrairement à Gentoo). Après mise à jours vers FC3 (via yum par exemple (même s'il y a quelques points durs [*])) t'as un système stable (supporté) plus à jours que Gentoo. Certe, celui qui veut la dernière nouveauté qui est sorti la veille sera un peu grinceux car les développeurs seront concentrés principalement sur la nouvelle branche de développement.
La force de Gentoo n'est pas dans le niveau de mise à jours (même si fort respectable) mais dans la combinaison "souplesse de la configuration"/"niveau de mise à jour". Sur le point, elle met la pâté à tout le monde :-). Y a pas photo.
> C'est peu être un peu le cas de debian testing, qui si j'ai bien compris passe quand même par une certaine dose de QA,
C'est là qu'on voit que ça ne marche pas dans la pratique :-)
Qu'il y a toujours un moment ou il faut une rupture. Sinon tu es englué dans des problèmes de compatibilité, de mise à jours etc...
[*] http://fedora.linux.duke.edu/FC3-rc1/3/i386/os/RELEASE-NOTES-en.htm(...)
Chercher "upgrade to udev using the following steps".
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.