Como faço para usar um fornecedor Apache com Perl e mod_perl autocompilados?

Question

Quero usar o Apache integrado da Apple ou RedHat, mas quero usar Perl 5.10 e mod_perl.Qual é a maneira menos intrusiva de conseguir isso?Quero a vantagem de patches de segurança gratuitos para Apache, dav, php, etc. do fornecedor, mas me preocupo muito com qual versão do Perl uso e o que está em meu caminho @INC.Não me importo de compilar meu próprio mod_perl.

Answer 1

1. Construa sua versão do Perl 5.10 seguindo instruções especiais da documentação do mod_perl.Diga ao configurador Perl para instalar em algum local não padrão, como /usr/local/perl/5.10.0

2. Use as instruções para construir uma biblioteca compartilhada (ou dinâmica, ou .so) mod_perl no Apache da sua distribuição, mas certifique-se de executar o Makefile.PL usando seu versão do perl:

   /usr/local/perl/5.10.0/bin/perl Makefile.PL APXS=/usr/bin/apxs

3. Instale e configure o mod_perl normalmente.

Pode ser útil, após o primeiro passo, alterar seu caminho para que você não fique acidentalmente confuso sobre qual versão do Perl está usando:

export PATH=/usr/local/perl/5.10.0/bin:$PATH

Answer 2

Você vai querer dar uma olhada mod_so

Answer 3

Eu já fiz isso antes.Não foi bonito, mas funcionou, especialmente porque os perls dos fornecedores geralmente têm de 2 a 3 anos.

Comecei criando meu próprio RPM perl que instalou o perl em um local diferente, como /opt/.Isso foi bastante simples.Comecei principalmente com isso porque não queria que os utilitários do sistema que usavam perl quebrassem quando eu atualizasse/instalasse novos módulos.Tive que modificar todos os meus scripts para especificar #!/opt/bin/perl no topo e às vezes até brinquei com o caminho para ter certeza de que meu perl vinha primeiro.

Em seguida, peguei um RPM de origem mod_perl e modifiquei-o para usar meu /opt/bin/perl em vez de /usr/bin/perl.Não tenho acesso às alterações que fiz, pois foi em um show diferente.Levei um pouco de brincadeira para conseguir.

Funcionou, mas não sou um assistente de RPM, então a verificação de dependências não funcionou tão bem.Por exemplo, eu poderia desinstalar meu RPM personalizado e quebrar tudo.Não foi grande coisa para mim, então segui em frente.

Eu também estava misturando RPMs com instalações de módulos CPAN (já mencionei que construímos nosso próprio espelho CPAN personalizado com nosso próprio código?).Isso também era um pouco frágil.Novamente, eu não tinha recursos (ou seja, tempo) para descobrir como dobrar cpan2rpm para usar meu perl e não causar conflitos de RPM.

Se eu tivesse que fazer tudo de novo, faria um RPM perl personalizado de 5,10 e apenas substituiria o perl do sistema.Então eu usaria cpan2rpm para criar os pacotes RPM necessários para meu software e compilar meu próprio RPM mod_perl.