Eu criei várias aplicações web PHP que distribuí (internamente) através de pacotes Debian. Isso foi simples graças aos scripts (simplificados aqui) para automatizar o processo:
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
controle :
Package: myapp
Version: 1.2.3
Maintainer: Your Name <yourname@email.com>
Architecture: all
Depends: apache2, php5
Description: The myapp web application.
Tudo isso é bastante fácil de fazer e funciona bem para a distribuição interna de pacotes que eu faço. Não tenho certeza de que seja suficiente para distribuição global, mas pode ser semelhante ao que o pessoal do Ubuntu e Debian fazem quando pegam pacotes de código-fonte (provavelmente distribuídos como tarballs com scripts de instalação) e criam pacotes .deb para eles.
Eu acho que isso pode resolver seus cinco pontos sem problemas:
O pacote Debian se descompacta automaticamente no local apropriado no sistema de destino quando é instalado.
Você pode fazer com que o pacote Debian configure o Apache automaticamente. Alguns pacotes como MySQL e Apache possuem diretórios "conf.d" no / etc nos quais você pode soltar arquivos de configuração. Esse é o ideal. Seu script de empacotamento pode criar um diretório debian / etc / apache2 / conf.d e copiar um arquivo de configuração lá. Ele será instalado no sistema de destino e você poderá reiniciar o Apache em um script chamado postinst que você colocar no debian / DEBIAN.
Provavelmente, isso é inevitável se as informações personalizadas tiverem que ser inseridas, embora muitos prefiram sistemas que podem ser executados "fora da caixa" sem a necessidade de configuração.
A existência da biblioteca pode ser garantida incluindo as dependências de pacote apropriadas no arquivo de controle. As informações de conexão com o banco de dados podem ser instaladas como padrão ou solicitadas ao administrador nas páginas de configuração. Uma vez inseridas, as páginas de configuração devem chamar scripts de migração de banco de dados idempotentes para atualizar o esquema do banco de dados. Várias estruturas da web (como o Django) facilitam isso.
O código por trás das páginas de configuração deve marcar o sistema como configurado, não o administrador.
Uma abordagem que às vezes uso é separar a instalação da configuração da instalação do aplicativo, tornando-os pacotes separados. Posso então ter vários pacotes de configuração diferentes (release, desenvolvimento etc.) que posso instalar à vontade. Esse desacoplamento também é vantajoso porque a configuração e o aplicativo podem evoluir separadamente, sem atrapalhar o outro quando reinstalados.