Quais pacotes devem ser reconstruídos após a atualização gccem um sistema gentoo? É suficiente executar
# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`
como sugerido semelhante para perl nesta FAQ ?
Quais pacotes devem ser reconstruídos após a atualização gccem um sistema gentoo? É suficiente executar
# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`
como sugerido semelhante para perl nesta FAQ ?
Respostas:
TL; DR
Eu tenho uma opinião diferente sobre isso como usuário do Gentoo. Embora eu concorde com a abordagem de peterph de "Deixe o sistema decidir", eu discordo quando se trata de uma atualização ABI . Às vezes, uma atualização ABI é uma grande mudança de comportamento. No caso do GCC 4.7, a ABI Change foi a adoção do novo C ++ 11 Standard, que Peter também apontou.
Aqui está o porquê de eu escrever esta resposta. Eu sou um viciado em padrões. Comecei no mundo da web quando havia cerca de 4 navegadores diferentes e uma infinidade de tags em HTML que eram suportadas apenas por determinados navegadores. Naquela época, todas essas tags aumentavam a confusão, e a IMO tornava o trabalho mais difícil. O C ++ foi padronizado pelo mesmo motivo, em suma, para que você possa compilar o código que eu escrevo e posso compilar o código que você escreve . Se optarmos por não seguir um padrão, perderemos a liberdade de compartilhar.
O C ++ 98 é o padrão aprovado há 13 anos. O C ++ 11 foi ratificado pelo Comitê ISO em 2011 e foi completamente integrado ao GCC 4.7. Veja o status ISO atual e o novo padrão ISO .
Como usuários de uma distribuição baseada na fonte, temos a oportunidade única de moldar o comportamento futuro de um pacote, porque o compilamos antes de usá-lo. Como tal, para se preparar para essa oportunidade, acho que os seguintes comandos devem ser executados ao atualizar para o novo compilador:
emerge -ev system
gcc-config -l && gcc-config *new compiler name*
env-update && source /etc/profile
emerge -1v libtool
emerge -ev system
A primeira passagem pelo sistema cria o novo compilador, e suas dependências, com o compilador antigo. A segunda passagem pelo sistema reconstrói o novo compilador e suas dependências com o novo compilador. Especificamente, queremos fazer isso para que nosso Build Chain aproveite os novos recursos do novo compilador, se os pacotes do Build Chain também tiverem sido atualizados ... Algumas pessoas substituem a 2ª passagem pelo sistema pelo conjunto mundial, embora eu achamos que isso é um exagero, pois não sabemos quais pacotes já suportam o novo padrão, mas queremos que nossa cadeia de construção se comporte de maneira saudável.
Fazer isso pelo menos no conjunto de sistemas, nos prepara para testar todos os pacotes que compilamos em relação ao novo padrão, porque usamos uma versão sem interrupção. Desta forma, adicionando -std=c++11para CXXFLAGSdepois de atualizar a cadeia de construção nos permite teste para a ruptura, e ser capaz de enviar bugs diretamente para tanto o nosso bugzilla ou a montante para os desenvolvedores reais pela simples razão de:
Ei, seu pacote blá blá quebra usando o novo padrão C ++, e eu anexei meu log de compilação.
Considero isso uma cortesia para os desenvolvedores, pois agora eles têm tempo para se preparar, à medida que o padrão se torna mais amplamente adotado, e o antigo padrão é eliminado. Imagine a comoção da parte do desenvolvedor se ele recebeu centenas de bugs, porque esperou até que o padrão fosse eliminado ...
Nenhuma outra distribuição que eu conheço pode usar esse método, pois os mantenedores de pacotes reais existem como intermediários antes que um patch ou atualização possa ser usado pela respectiva comunidade de usuários. Nós temos mantenedores, mas também temos a capacidade de usar uma árvore de portage local.
Não sei se a recompensa foi publicada porque todos vocês gostam das minhas respostas perspicazes e bem pensadas, mas em uma tentativa de recompensa, tentarei responder à sua oferta perspicaz e bem pensada. Primeiro, deixe-me dizer em resposta que, como usuário de uma distribuição baseada na fonte, acredito firmemente que o que liga os pontos é tudo o que você pediu em sua solicitação de recompensa. Alguém pode ser um ótimo codificador, mas tem um cuidado ruim com o software. Da mesma forma, existem pessoas que são codificadores ruins que têm muito cuidado com o software.
Antes de vir para cá, eu era um ávido pôster nos fóruns do Gentoo . Finalmente percebi, quando comecei a vir aqui, que todo mundo tem algum grau de talento que pode usar. É o que eles escolhem fazer com isso que faz a diferença de contribuição. Alguns de nós somos ótimos escritores (não eu), portanto, se você deseja contribuir com algum projeto, mas não escreve ou não pode escrever código ou corrigir bugs, lembre-se de que grandes escritores podem escrever boa documentação ou ótimos artigos da Wiki .
O padrão existe por outro motivo: em uma comunidade, certas regras são esperadas de seus membros . Siga essa declaração aqui também. Se eu enviar uma correção, patch, aprimoramento etc. e não houver padrões, o patch funcionará apenas nas situações que considero importantes, ou seja, se eu estiver usando o whizbang compiler 2.0, e o patch for construído no whizbang compiler 1.0, vai falhar. Como o esforço é para uma comunidade, a comunidade espera que tudo funcione na maioria das situações; portanto, em vez de forçar todos os usuários a atualizarem para o compilador 2, posso estipular em um padrão:
Este pacote escolhe permitir compatibilidade com versões anteriores com o Whizbang Compiler 1.0
Dessa maneira, como desenvolvedor, codificador de baixa qualidade ou não, sei que devo usar ou pelo menos testar o Compiler Versão 1.0. Como usuário, por outro lado, posso escolher o que quero fazer. Se estou insatisfeito, posso solicitar um patch, enviando um bug ou o outro extremo de "Este software é uma porcaria!", E não faço nada. Independentemente disso, o usuário e o desenvolvedor entendem o padrão porque ele foi escrito.
A ponte entre a ação e a ação de alguma forma é requerida por todos os usuários, o que exige que tudo o que você pediu para que eu e outras pessoas comentem, e devemos confiar na comunidade de usuários e em seus talentos de todas as formas que preenchem essa lacuna. Se você optar por ser um dos usuários contribuintes, eu aplaudo. Para aqueles de vocês que optam por ser inativos, lembre-se de que, se quiser algo consertado, os ativos precisam de sua contribuição. Então, estou lhe dizendo, não tenha vergonha de enviar um bug ou de nos dizer que precisamos atualizar a documentação e, se formos rudes, conte-nos ou encontre outra pessoa até encontrar sua área de especialização.
Depende muito do tipo de atualização do compilador que você fez. Se tiver sido substancial, tudo deverá ser recompilado *) devido a possíveis alterações na ABI pelo compilador. Em muitos casos, não será necessário, mas se seus pacotes dependem de algo como C ++ 11, você pode ter problemas - veja, por exemplo, as notícias do Gentoo sobre a alteração da ABI no GCC 4.7 ou no GCC bugzilla .
*) Observe a ênfase em "recompilado" - definitivamente não faz muito sentido recompilar (ler reconstruir) um aplicativo Python ou Perl porque você alterou um compilador C. A menos que tenha também um componente nativo (o que pode acontecer).