C'est comme tu veux que se soit, rien ne t'oblige à te mettre à jour quotidiennement. La différence est principalement qu'il n'y a aucune raison que le moment où toi tu te figes corresponde à une quelconque version officielle. Ne mettre à jour que les paquets dans lesquels des bugs nous énervent ou sur lesquels il y a des alertes est parfaitement possible. Pour les mises à jours de sécurité, l'automatisation n'est effectivement pas encore super bien intégrée (cf. mon post un peu plus bas sur "glsa-check"), mais bon, de toute façon si ça t'importe vraiment, les GLSA tu t'y abonnes par mail et tu les appliques à la main (je dirais qu'il y en a 2 ou 3 par semaine, c'est pas la mer à boire). Si tu fouine un peu dans le forum, tu verras que des gens avec des serveurs sérieux ou des parcs de station sous Gentoo, il y en a de plus en plus. La politique des admins n'est alors clairement pas de faire des "emerge -uD world" quotidien, mais se base plutôt sur des màj parcimonieuses, avec pour les parcs un snapshot de l'arbre et des paquets binaires partagés sur le réseau, ce genre de chose. Bref, question de méthode, mais y'en a pour tout les goût.
- Certains codes sources récupérés chez sourceforge lors d'un emerge n'arrivent pas à être téléchargés facilement.
Bah y'en a quand même pas mal des mirroirs sourceforge, ça ferait un peu double emploi de coller ces fichiers là sur les mirroirs Gentoo (or c'est quand même une grosse quantité de fichiers qui est concernée). Par contre ils ne sont effectivement pas tous listés dans le profiles/thirdpartymirrors officiel, et ceux qui y sont privilégient surtout les US et le Japon. Perso j'en ai rajouté deux dans mon /etc/portage/mirrors qui le font mieux pour la France, et je n'ai jamais le moindre problème.
- Enfin, il est rageant de voir la compilation de Ooo échouer [...] Je n'ai apparament pas trouvé de mécanisme pour faire ceci et çà doit se gérer en bricolant à la mano.
Perso je trouve absurde de compiler soit même OOo (même si je l'ai déjà fait), il n'y a ni optimisation possible (OOo est très strict sur les CFLAGS acceptés), ni option de configuration commandée par des USE flags. Ça reviens donc en gros à refaire les GRP chez soit, ça ne sert à peu près rien. Mais sur d'autres exemples, la reprise de compilation est effectivement un truc qui sert parfois (perso je suis en ~x86, et des paquets qui compilent pas, ça arrive. Alors je patch et je relance.) : c'est avec la commande "ebuild" que ça se fait. En gros, "emerge" fait lui systématiquement toute les étapes, du unpack des sources au merge, alors que justement "ebuild" permet de faire ces étapes individuellement.
il ne faut pas vouloir être pressé pour essayer certains paquets et se rendre compte au final que le logiciel installé n'était pas tip top
Pour essayer sur un coup de tête un gros logiciel, ayez le réflexe GRP. Et ça le fait mais que ça pourrait être mieux avec d'autres USE flags, ou bien qu'il y a peut-être à gratter niveau optimisation, ou encore qu'il n'y avait pas de GRP pour la dernière version toute fraiche, alors lancer l'emerge normal en tâche de fond, tout en continuant à jouer avec la version binaire.
[^] # Re: "not for profit"
Posté par tgl . En réponse à la dépêche Distribution Gentoo : des nouvelles du front. Évalué à 3.
C'est comme tu veux que se soit, rien ne t'oblige à te mettre à jour quotidiennement. La différence est principalement qu'il n'y a aucune raison que le moment où toi tu te figes corresponde à une quelconque version officielle. Ne mettre à jour que les paquets dans lesquels des bugs nous énervent ou sur lesquels il y a des alertes est parfaitement possible. Pour les mises à jours de sécurité, l'automatisation n'est effectivement pas encore super bien intégrée (cf. mon post un peu plus bas sur "glsa-check"), mais bon, de toute façon si ça t'importe vraiment, les GLSA tu t'y abonnes par mail et tu les appliques à la main (je dirais qu'il y en a 2 ou 3 par semaine, c'est pas la mer à boire). Si tu fouine un peu dans le forum, tu verras que des gens avec des serveurs sérieux ou des parcs de station sous Gentoo, il y en a de plus en plus. La politique des admins n'est alors clairement pas de faire des "emerge -uD world" quotidien, mais se base plutôt sur des màj parcimonieuses, avec pour les parcs un snapshot de l'arbre et des paquets binaires partagés sur le réseau, ce genre de chose. Bref, question de méthode, mais y'en a pour tout les goût.
- Certains codes sources récupérés chez sourceforge lors d'un emerge n'arrivent pas à être téléchargés facilement.
Bah y'en a quand même pas mal des mirroirs sourceforge, ça ferait un peu double emploi de coller ces fichiers là sur les mirroirs Gentoo (or c'est quand même une grosse quantité de fichiers qui est concernée). Par contre ils ne sont effectivement pas tous listés dans le profiles/thirdpartymirrors officiel, et ceux qui y sont privilégient surtout les US et le Japon. Perso j'en ai rajouté deux dans mon /etc/portage/mirrors qui le font mieux pour la France, et je n'ai jamais le moindre problème.
- Enfin, il est rageant de voir la compilation de Ooo échouer [...] Je n'ai apparament pas trouvé de mécanisme pour faire ceci et çà doit se gérer en bricolant à la mano.
Perso je trouve absurde de compiler soit même OOo (même si je l'ai déjà fait), il n'y a ni optimisation possible (OOo est très strict sur les CFLAGS acceptés), ni option de configuration commandée par des USE flags. Ça reviens donc en gros à refaire les GRP chez soit, ça ne sert à peu près rien. Mais sur d'autres exemples, la reprise de compilation est effectivement un truc qui sert parfois (perso je suis en ~x86, et des paquets qui compilent pas, ça arrive. Alors je patch et je relance.) : c'est avec la commande "ebuild" que ça se fait. En gros, "emerge" fait lui systématiquement toute les étapes, du unpack des sources au merge, alors que justement "ebuild" permet de faire ces étapes individuellement.
il ne faut pas vouloir être pressé pour essayer certains paquets et se rendre compte au final que le logiciel installé n'était pas tip top
Pour essayer sur un coup de tête un gros logiciel, ayez le réflexe GRP. Et ça le fait mais que ça pourrait être mieux avec d'autres USE flags, ou bien qu'il y a peut-être à gratter niveau optimisation, ou encore qu'il n'y avait pas de GRP pour la dernière version toute fraiche, alors lancer l'emerge normal en tâche de fond, tout en continuant à jouer avec la version binaire.