Quels packages doivent être reconstruits après la mise gccà niveau sur un système Gentoo? Est-il suffisant de courir
# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`
comme suggéré similaire pour perl dans cette FAQ ?
Quels packages doivent être reconstruits après la mise gccà niveau sur un système Gentoo? Est-il suffisant de courir
# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`
comme suggéré similaire pour perl dans cette FAQ ?
Réponses:
TL; DR
J'ai une vision différente de cela en tant qu'utilisateur Gentoo. Bien que je sois d'accord avec l'approche de Peter de «Laissez le système décider», je ne suis pas d'accord quand il s'agit d'une mise à jour ABI . Une mise à jour ABI est parfois un changement majeur de comportement. Dans le cas de GCC 4.7, le changement ABI a été l'adoption de la nouvelle norme C ++ 11, que Peter Peterph a également souligné.
Voici pourquoi j'écris cette réponse. Je suis accro aux normes. J'ai commencé dans le monde du Web quand il y avait environ 4 navigateurs différents et une pléthore de balises en HTML qui n'étaient prises en charge que par certains navigateurs. À l'époque, toutes ces étiquettes ont accru la confusion et l'OMI a rendu le travail plus difficile. C ++ a été normalisé pour cette même raison, en bref pour que vous puissiez compiler le code que j'écris et que je puisse compiler le code que vous écrivez . Si nous choisissons de ne pas suivre une norme, nous perdons la liberté de partager.
C ++ 98 est la norme approuvée depuis 13 ans. C ++ 11 a été ratifié par le comité ISO en 2011 et a été complètement intégré dans GCC 4.7. Voir l' état ISO actuel et la nouvelle norme ISO .
En tant qu'utilisateurs d'une distribution basée sur la source, nous avons l'occasion unique de façonner le comportement futur d'un package, car nous le compilons avant de l'utiliser. En tant que tel, pour préparer cette opportunité, j'estime que les commandes suivantes doivent être exécutées lors de la mise à jour vers le nouveau compilateur:
emerge -ev system
gcc-config -l && gcc-config *new compiler name*
env-update && source /etc/profile
emerge -1v libtool
emerge -ev system
Le premier système pass through construit le nouveau compilateur, et ses dépendances, avec l'ancien compilateur. Le second système pass through reconstruit le nouveau compilateur et ses dépendances avec le nouveau compilateur. Plus précisément, nous voulons le faire pour que notre chaîne de build profite des nouvelles fonctionnalités du nouveau compilateur, si les packages de la chaîne de construction ont également été mis à jour ... trouver cela excessif, car nous ne savons pas quels packages prennent déjà en charge la nouvelle norme, mais nous voulons que notre chaîne de construction se comporte de manière saine.
Faire cela pour au moins l'ensemble du système, nous prépare à tester chaque package que nous compilons par rapport à la nouvelle norme, car nous utilisons une version continue. De cette façon, en ajoutant -std=c++11à CXXFLAGSaprès la mise à jour de la chaîne de construction nous permet de tester la rupture, et être en mesure de présenter des bugs directement soit notre bugzilla ou en amont aux développeurs réels pour la raison simple:
Hé, votre paquet bla bla casse en utilisant le nouveau standard C ++, et j'ai joint mon journal de build.
Je considère cela comme une courtoisie envers les développeurs, car ils ont maintenant le temps de se préparer à mesure que la norme devient plus largement adoptée et que l'ancienne norme est progressivement supprimée. Imaginez l'agitation du développeur s'il a reçu des centaines de bugs, car il a attendu que la norme soit supprimée ...
Aucune autre distribution que je connaisse ne peut utiliser cette méthode car les responsables de package réels existent en tant qu'intermédiaires avant qu'un correctif ou une mise à jour puisse être utilisé par la communauté d'utilisateurs respective. Nous avons des mainteneurs, mais nous avons également la possibilité d'utiliser un arbre de portage local.
Je ne sais pas si la prime a été publiée parce que vous aimez tous mes réponses perspicaces et bien pensées, mais dans une tentative de prime, je vais essayer de répondre à votre offre de prime perspicace et bien pensée. Tout d'abord, permettez-moi de dire en réponse qu'en tant qu'utilisateur d'une distribution basée sur la source, je crois fermement que ce qui relie les points sont toutes les choses que vous avez demandées dans votre demande de prime. Quelqu'un peut être un excellent codeur, mais il a un faible pour les logiciels. De la même manière, il y a des gens qui sont des codeurs de merde qui ont un grand soin pour les logiciels.
Avant de venir ici, j'étais une affiche passionnée, sur les forums Gentoo . J'ai finalement réalisé quand j'ai commencé à venir ici que tout le monde avait un certain talent qu'il pouvait utiliser. C'est ce qu'ils choisissent d'en faire qui fait la différence. Certains d'entre nous sont de grands écrivains (pas moi), donc si vous voulez contribuer à un projet, mais que vous ne pouvez pas ou ne pouvez pas écrire de code, ou corriger des bugs, n'oubliez pas que les grands écrivains peuvent écrire une excellente documentation, ou de grands articles Wiki .
La norme est là pour une autre raison: dans une communauté, certaines règles sont attendues de ses membres . Suivez cette déclaration ici aussi. Si je soumets un correctif, un correctif, une amélioration, etc. et qu'il n'y a pas de normes, le correctif ne fonctionnera que dans les situations que je considère importantes, c'est-à-dire si j'utilise le compilateur whizbang 2.0 et que le correctif est construit contre le compilateur whizbang 1.0, il échouera. Puisque l'effort est pour une communauté, la communauté s'attend à ce que tout fonctionne dans la plupart des situations, donc au lieu de forcer tous les utilisateurs à passer au compilateur 2, je peux stipuler dans une norme:
Ce package choisit d'autoriser la compatibilité descendante avec Whizbang Compiler 1.0
De cette façon, en tant que développeur, codeur merdique ou non, je sais que je dois utiliser ou au moins tester avec Compiler Version 1.0. En tant qu'utilisateur, en revanche, je peux choisir ce que je veux faire. Si je ne suis pas satisfait, je peux demander un patch, en soumettant un bug, ou l'autre extrême de "Ce logiciel est un morceau de merde !," et ne rien faire. Quoi qu'il en soit, l'utilisateur et le développeur comprennent la norme car elle a été écrite.
Combler le fossé nécessite une action de la part d'un utilisateur, et cela nécessite toutes les choses que vous m'avez demandé, ainsi que d'autres, de commenter, et nous devons compter sur la communauté des utilisateurs et leurs talents sous toutes leurs formes pour combler ce fossé. Si vous choisissez d'être l'un des utilisateurs contributeurs, je vous félicite. Pour ceux d'entre vous qui choisissent d'être inactifs, rappelez-vous que si vous voulez quelque chose de fixe, les actifs ont besoin de votre contribution. Donc, je vous le dis, n'hésitez pas à soumettre un bogue, ou à nous dire que nous devons mettre à jour la documentation, et si nous sommes impolis, dites-le-nous, ou trouvez quelqu'un d'autre, jusqu'à ce que vous trouviez votre domaine d'expertise.
Cela dépend beaucoup du type de mise à niveau du compilateur que vous avez fait. S'il a été substantiel, alors tout devrait être recompilé *) à cause des changements possibles dans ABI par le compilateur. Dans de nombreux cas, cela ne sera pas nécessaire, mais si vos packages dépendent de quelque chose comme C ++ 11, alors vous pourriez rencontrer des problèmes - voir par exemple les nouvelles Gentoo sur le changement d'ABI dans GCC 4.7 ou GCC bugzilla .
*) Notez l'accent mis sur "recompilé" - cela n'a certainement pas beaucoup de sens de recompiler (lire reconstruire) une application Python ou Perl parce que vous avez changé un compilateur C. À moins qu'il n'ait également un composant natif (ce qu'il pourrait bien faire).