Many PHP web applications follow this model for installation and upgrade:
- Un-tar a source tar ball.
- Point Apache at the source.
- Navigate a web browser to the home page.
- Go through several web pages of set-up (e.g., checks for existence of libraries, asks for database connection information, creates or updates database schema, etc.).
- User renames an
install/directory to something else so that application knows it has been installed.
I don’t see any (simple) way to create a Debian package out of this without making the user installing the package go through many of the above manual steps. Note that I am not a developer on the application so I am not in a position to make direct change to how the application installation works.
What is the typical approach to packaging such an application?
1
I have created several PHP web applications that I distribute (internally) through Debian packages. Doing so has been straightforward thanks to scripts (simplified here) to automate the process:
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.
All this is fairly easy to do, and works well for the internal package distribution that I do. I am not sure it is sufficient for global distribution, but it might be similar to what the Ubuntu and Debian people do when they take source packages (probably distributed as tarballs with install scripts) and create .deb packages for them.
I think this can address your five points smoothly:
-
The Debian package automatically decompresses into the proper place on the target system when it is installed.
-
You can have the Debian package configure Apache automatically. Some packages like MySQL and Apache have “conf.d” directories in /etc into which you can drop configuration files. This is the ideal. Your packaging script can create a debian/etc/apache2/conf.d directory and copy a configuration file in there. It will be installed on the target system, and you can restart Apache in a script called postinst that you place in debian/DEBIAN.
-
This is probably unavoidable if custom information must be entered, though many prefer systems that can run “out of the box” with no configuration required.
-
Library existence can be guaranteed by including the appropriate package dependencies in the control file. Database connection information can be either installed as a default, or asked of the administrator on the configuration pages. Once entered, the configuration pages should invoke idempotent database migration scripts to update the database schema. Several web frameworks (like Django) make this easy.
-
The code behind the configuration pages should mark the system as configured, not the administrator.
An approach I sometimes use is to separate installation of configuration from installation of the app by making them separate packages. I can then have several different configuration packages (release, development, etc.) that I can install at will. This decoupling is also advantageous because configuration and app can evolve separately, without clobbering each other when reinstalled.
0