Skip to content. Skip to navigation

Ian Lawrence

Personal tools
You are here: Home Blog Packaging Web Applications in Debian

Packaging Web Applications in Debian

$ tar xfz webapp-1.0.tgz;cd webapp-1.0;dh_make_webapp

Modern apps are web based but we have no real standardized way to package them. Partly this is because Javascript is still in the 'vote with your feet' stage of standardization but also because of the complexity involved in the client/server exchange (i.e sorry dude, the code runs where again?)
So what best practices do we currently have in Debian?


This package presents a policy and implementation for managing various databases used by applications included in Debian packages. I have just proposed an integration of django evolution into this package. This will allow us to track changes in our Django models over time, and to update the database to reflect those changes.

Javascript Packaging

This is provided in Debian by the package javascript-common and it allows javascript libraries to be installed in

and makes them automatically available in Apache at

The Debian Webapps Policy Document

This was first drafted in 2005 and is undergoing revision here @ Debconf.
Web applications should not make any assumption about how the administrator has arranged the file hierarchy on the target machine.

The suggested guidelines for the layout of an application are:

  • Static and dynamically interpreted content
  • /usr/share/PACKAGE/www
  • Dynamically executed content
  •     A unique subdirectory of either
    /usr/lib/PACKAGE (architecture-dependant)
    or A unique subdirectory of
    /usr/share/PACKAGE (architecture-independant)
  • Application-specific include files
  • A unique subdirectory of
  • Other static data, and helper scripts that don't belong in users' paths
  • A unique subdirectory of
  • Site configuration (settings/passwords)
  • /etc/PACKAGE
  • Modifiable and overridable content
  • A subdirectory of

    Specific Requirements for Programming Languages

    The web application policy divides includable files into two distinct categories:
    application-specific and site-wide.

    The former includes files not intended for use outside of the particular application in question, and the latter addresses files intended for more general use. As previously mentioned, application-specific include files should exist in a unique subdirectory of /usr/share/PACKAGE. This subdirectory should exist outside of any web-accessible directory, as many security-related problems in poorly written web applications are the direct result of not doing so.

    Whilst the Policy Manual has specific requirements for PHP and Perl there is nothing yet for Python. I am currently working on this and it will likely be based closely on the Perl Policy document. Comments and suggestions are welcome.

    Thursday, August 14, 2008 in CodeWork  | Permalink |  Comments (0)   Digg   Yahoo   Google   Spurl
    « May 2020 »
    Su Mo Tu We Th Fr Sa
    1 2
    3 4 5 6 7 8 9
    10 11 12 13 14 15 16
    17 18 19 20 21 22 23
    24 25 26 27 28 29 30
    Borala (4)
    Bricolabs (12)
    Code (57)
    Estudiolivre (12)
    Life (26)
    MetaReciclagem (9)
    Thoughts (16)
    Work (41)