He creado varias aplicaciones web PHP que distribuyo (internamente) a través de paquetes Debian. Hacerlo ha sido sencillo gracias a los scripts (simplificados aquí) para automatizar el proceso:
create_package.sh :
# create a clean debian package directory
rm -rf debian
mkdir -p debian/DEBIAN
mkdir -p debian/var/www/myapp
# populate the debian directory
cp control debian/DEBIAN
cp myapp.php debian/var/www/myapp
cp index.html debian/var/www/myapp
# finish through fakeroot so we can adjust ownerships without needing to be root
fakeroot ./finish_package.sh debian .
finish_package.sh :
# $1 is the debian directory, $2 is the output directory
# adjust ownerships
chown -R root:root $1
chown -R nobody:nobody $1/var/www/myapp
# finally build the package
dpkg-deb --build $1 $2
control :
Package: myapp
Version: 1.2.3
Maintainer: Your Name <[email protected]>
Architecture: all
Depends: apache2, php5
Description: The myapp web application.
Todo esto es bastante fácil de hacer y funciona bien para la distribución interna de paquetes que hago. No estoy seguro de que sea suficiente para la distribución global, pero podría ser similar a lo que hacen las personas de Ubuntu y Debian cuando toman paquetes de origen (probablemente distribuidos como archivos comprimidos con scripts de instalación) y crean paquetes .deb para ellos.
Creo que esto puede abordar sus cinco puntos sin problemas:
-
El paquete Debian se descomprime automáticamente en el lugar adecuado en el sistema de destino cuando se instala.
-
Puede hacer que el paquete Debian configure Apache automáticamente. Algunos paquetes como MySQL y Apache tienen directorios "conf.d" en / etc en los que puede colocar archivos de configuración. Este es el ideal. Su script de empaquetado puede crear un directorio debian / etc / apache2 / conf.d y copiar un archivo de configuración allí. Se instalará en el sistema de destino y puede reiniciar Apache en un script llamado postinst que coloque en debian / DEBIAN.
-
Probablemente esto sea inevitable si se debe ingresar información personalizada, aunque muchos prefieren sistemas que pueden ejecutarse "fuera de la caja" sin necesidad de configuración.
-
La existencia de la biblioteca se puede garantizar incluyendo las dependencias de paquetes apropiadas en el archivo de control. La información de conexión de la base de datos puede instalarse por defecto o solicitarse al administrador en las páginas de configuración. Una vez ingresadas, las páginas de configuración deben invocar scripts de migración de base de datos idempotent para actualizar el esquema de la base de datos. Varios marcos web (como Django) facilitan esto.
-
El código detrás de las páginas de configuración debe marcar el sistema como configurado, no el administrador.
Un enfoque que a veces utilizo es separar la instalación de la configuración de la aplicación haciendo paquetes separados. Entonces puedo tener varios paquetes de configuración diferentes (versión, desarrollo, etc.) que puedo instalar a voluntad. Este desacoplamiento también es ventajoso porque la configuración y la aplicación pueden evolucionar por separado, sin obstruirse entre sí cuando se reinstalan.