¿Cómo uso un proveedor Apache con Perl y mod_perl autocompilados?

Question

Quiero usar Apache integrado de Apple o RedHat pero quiero usar Perl 5.10 y mod_perl.¿Cuál es la forma menos intrusiva de lograr esto?Quiero la ventaja de parches de seguridad gratuitos para Apache, dav, php, etc. del proveedor, pero me importa mucho qué versión de Perl uso y qué hay en mi ruta @INC.No me importa compilar mi propio mod_perl.

Answer 1

1. Construya su versión de Perl 5.10 siguiendo las instrucciones especiales de la documentación mod_perl.Dígale al configurador de Perl que lo instale en algún lugar no estándar, como /usr/local/perl/5.10.0

2. Utilice las instrucciones para crear una biblioteca compartida (o dinámica, o .so) mod_perl contra el Apache de su distribución, pero asegúrese de ejecutar Makefile.PL usando su versión de perl:

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

3. Instale y configure mod_perl como de costumbre.

Puede resultar útil, después del paso uno, cambiar la ruta para no confundirse accidentalmente acerca de qué versión de Perl está utilizando:

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

Answer 2

Querrás investigar mod_so

Answer 3

He hecho esto antes.No fue bonito, pero funcionó, especialmente porque los proveedores de Perl suelen tener entre 2 y 3 años.

Comencé creando mi propio RPM de Perl que instalaba Perl en una ubicación diferente, como /opt/.Esto fue bastante sencillo.Principalmente comencé con esto porque no quería que las utilidades del sistema que usaban Perl se estropearan cuando actualizaba/instalaba nuevos módulos.Tuve que modificar todos mis scripts para especificar #!/opt/bin/perl en la parte superior y, a veces, incluso jugué con la ruta para asegurarme de que mi Perl fuera lo primero.

Luego, tomé un RPM fuente mod_perl y lo modifiqué para usar mi /opt/bin/perl en lugar de /usr/bin/perl.No tengo acceso a los cambios que hice, ya que fue en un concierto diferente.Me tomó un poco de juego conseguirlo.

Funcionó, pero no soy un asistente de RPM, por lo que la verificación de dependencias no funcionó tan bien.Por ejemplo, podría desinstalar mi RPM personalizado y romperlo todo.No fue gran cosa para mí, así que seguí adelante.

También estaba mezclando RPM con instalaciones de módulos CPAN (¿mencioné que construimos nuestro propio espejo CPAN personalizado con nuestro propio código?).Esto también era un poco frágil.Una vez más, no tenía los recursos (es decir, el tiempo) para descubrir cómo doblar cpan2rpm usar mi perl y no causar conflictos de RPM.

Si tuviera que hacerlo todo de nuevo, crearía un RPM de Perl 5.10 personalizado y simplemente reemplazaría el sistema Perl.Entonces yo usaría cpan2rpm para crear los paquetes RPM que necesitaba para mi software y compilar mi propio RPM mod_perl.