Compilar meu próprio python quebrou scripts do sistema?

Question

(Para aqueles que não estão familiarizados com isso, o CrunchBang é basicamente um Debian Squeeze pré-configurado.)

Então, um tempo atrás, eu estava escrevendo um script e queria usar um recurso Python introduzido em 2.7. Já que a versão mais recente que eu pude obter do repositório apt do Debian Squeeze é 2.6.6.8, eu decidi baixar o último código fonte e construí-lo eu mesmo. Depois de resolver dependências, finalmente consegui trabalhar e terminei meu projeto.

No entanto, desde então, vários scripts do sistema pararam de funcionar. Eu notei que eles (os scripts agora quebrados) todos começam com #!/usr/bin/env python [1] e dependem de uma ou mais coisas que foram instaladas pelo apt-get / synaptic, mas estão associadas com o Python 2.6. Alguns consertei alterando manualmente o cabeçalho para #!/usr/bin/python , mas agora estou começando a me perguntar

1. Isso é normal para pessoas que usam seu próprio Python?
2. Eu compilei / configurei 2.7 de alguma forma errada?
3. Não é razoável esperar que pacotes instalados com o apt-get / synaptic se "travem" com a versão das dependências com as quais eles foram instalados?
4. Devo de alguma forma reconfigurar / igure meu $ PATH para que o arquivo /usr seja encontrado antes do arquivo /usr/local ?
5. Devo apenas excluir o arquivo de link físico / usr / local / bin / python e ter todos os meus scripts iniciados com #!/usr/local/bin/python2.7 ?
6. Preciso instalar manualmente todas as bibliotecas ausentes, etc., para /usr/local ? Se sim, qual é a melhor maneira de fazer isso?
7. Devo arquivar bugs com os mantenedores de pacotes, os próprios projetos ou ambos?

[1] Que, por causa de como meu caminho está configurado, invoca meu /usr/local/bin/python (2.7) em vez do /usr/bin/python (2.6)

do sistema     

Answer 1

Isso é normal o suficiente para que a maioria das pessoas que criam seus próprios ambientes em Python usem algo como virtualenv para gerenciar eles. Substituir o Perl, Python ou Ruby fornecido pelo sistema quase nunca é uma boa idéia, e todas as três linguagens fornecem maneiras para que os desenvolvedores gerenciem suas próprias instalações privadas (para Perl existe PerlBrew e para Ruby há RVM).