Basic webapp packaging questions

[Jonathan Nieder]

Hi,

I am dealing with an existing webapp package, namely gitweb; I thought
maybe the Debian webapps policy might give some guidance to getting it
to work well out of the box. Thanks to Charles Plessy for his work so
far in this regard.

Okay, so some questions:

1. What is the standard address for the webapps policy? I looked in
/usr/share/doc/debian-policy and found nothing, then
http://webapps-common.alioth.debian.org/draft/html/ and found
“Copyright © 2005-2006 The Debian Webapps Team” and “Revision:
DRAFT-1.10”, which left me unconfident that I have the latest version.

Related question: is there a page for the Debian webapps team on
wiki.debian.org?

2. What packages should a webapp depend on? For a simple CGI
script, would

apache2 | httpd-cgi

do? Is there a way to configure a webapp by default for arbitrary
servers providing httpd-cgi?

gitweb installs a configuration file in /etc/apache2/conf.d/gitweb.
Should it additionally Suggests: apache2?

3. How to handle changes in the files that should be served
statically? I imagine that to avoid installing stray files, some
existing web server configurations might include

Alias /gitweb.css /usr/share/gitweb/gitweb.css
Alias /gitweb.js /usr/share/gitweb/gitweb.js
Alias /git-favicon.png /usr/share/gitweb/git-favicon.png
Alias /git-logo.png /usr/share/gitweb/git-logo.png

Must there be an entry in NEWS.Debian.gz whenever a new file is added
or a file is moved? One could avoid that in the future (as upstream
does in current 1.7.2 release candidates) by changing the filesystem
layout to allow

Alias /static /usr/share/gitweb/static

Unfortunately, removing the old files would break gitweb during
upgrade. Suggestions?

I also wanted to thank you for the webapps policy and especially for
dbconfig-common. The standard quality for webapp packages is getting
a lot better.

Jonathan

[sean finney]

hi jonathan,

Post by Jonathan Nieder
1. What is the standard address for the webapps policy? I looked in
/usr/share/doc/debian-policy and found nothing, then
http://webapps-common.alioth.debian.org/draft/html/ and found
DRAFT-1.10”, which left me unconfident that I have the latest version.

i think that's the "authoritative" version, though there may be some
unpublished/uncommited changes in svn.

Post by Jonathan Nieder
Related question: is there a page for the Debian webapps team on
wiki.debian.org?

i don't think so. it's not so much a team as it's a group of people
who agreed on some general guidelines on a mailing list at some point :)

Post by Jonathan Nieder
2. What packages should a webapp depend on? For a simple CGI
script, would
apache2 | httpd-cgi
do? Is there a way to configure a webapp by default for arbitrary
servers providing httpd-cgi?

if it could possibly work with other cgi-serving applications (regardless
of whether you ship working configuration for the other variants), then yes
i think that makes sense. as for location, official debian policy says
you could drop files in /usr/lib/cgi-bin, though myself i'm not a huge
fan of that as a general rule since the scripts are able to be run as
soon as the package is unpacked, even if it's not configured. therefore
i suggest keeping things under /usr/{lib,share}/<package>/$subdir.

Post by Jonathan Nieder
gitweb installs a configuration file in /etc/apache2/conf.d/gitweb.
Should it additionally Suggests: apache2?

if it's in the dependencies listed above i don't think it's necessary.

Post by Jonathan Nieder
3. How to handle changes in the files that should be served
statically? I imagine that to avoid installing stray files, some
existing web server configurations might include
Alias /gitweb.css /usr/share/gitweb/gitweb.css
Alias /gitweb.js /usr/share/gitweb/gitweb.js
Alias /git-favicon.png /usr/share/gitweb/git-favicon.png
Alias /git-logo.png /usr/share/gitweb/git-logo.png

i think it depends on what's the easiest thing to do with the
original code. personally i'm a fan of compartmentalizing things
in different subdirectories underneath /usr/share/<pkg>, though if it's
only a small number of files the above would be reasonable too imho (as long
as the entire directory isn't being served by a single alias, which could
be problematic later on when you want to move stuff around.

Post by Jonathan Nieder
Must there be an entry in NEWS.Debian.gz whenever a new file is added
or a file is moved? One could avoid that in the future (as upstream
does in current 1.7.2 release candidates) by changing the filesystem
layout to allow
Alias /static /usr/share/gitweb/static

yeah that's something like what i was getting at above. I don't think
NEWS.gz entries would strictly be necessary unless you had some suspicion
that things would be more likely to break in a typical installation.

Post by Jonathan Nieder
Unfortunately, removing the old files would break gitweb during
upgrade. Suggestions?

i don't think it's worth a great deal of blood/sweat/tears to try and
keep things working during an apt-get upgrade window, since no matter
what there will probably be some short span where things are broken
no matter what while the package(s) are being unpacked and configured.

Post by Jonathan Nieder
I also wanted to thank you for the webapps policy and especially for
dbconfig-common. The standard quality for webapp packages is getting
a lot better.

\o/ :D


sean

[Jonathan Nieder]

Hi Sean,

Post by sean finney
i think that makes sense. as for location, official debian policy says
you could drop files in /usr/lib/cgi-bin, though myself i'm not a huge
fan of that as a general rule since the scripts are able to be run as
soon as the package is unpacked, even if it's not configured.

I found this comment very helpful.

Maybe policy § 11.5 needs updating. I am not volunteering for this
yet, just giving a heads up and hoping someone else will suggest
something. Maybe a list of changes that ought to be made in

http://webapps-common.alioth.debian.org/draft/html/

before it is ready to be proposed as policy.

[Nicholas Bamber]

Thanks to the archive for this mailing list I have answered some
questions. But I have a few more arriving out of my efforts at
rebuilding w3c-markup-validator.

1.) Currently w3c-markup-validator depends on apache2 | httpd though as
it is definitely a CGI script I think this should be apache2 | httpd-cgi.

2.) It claims to require SSI (mod_include) though I have a suspicion
this might just be Debian cruft. If it did what would be the best way of
handling it? Would the dependency have to be restricted to apache2?

3.) tntnet claims to be in the httpd-cgi virtual package but looking at
the description that does not make sense to me.

4.) The current package has stuff relating to apache, apache-perl and
apache-ssl. I reckon all of that is old Debian cruft. All of the
translation effort was focussed on that.

5.) Quoting from the current package
"If you are using the Debian package of Apache, Apache2, Apache-SSL or
Apache-Perl, the installation process of this package can automatically
update the webserver's configuration (using the wwwconfig-common program)
so that the package works without requiring a manual change. If you are
using any other server, you will have to configure it manually."


Is it acceptable that manual changes should be required for non-apache
or could wwwconfig-common be extended to cope
? I suppose that would require something to read the apache config
fragments and convert it into the format used by the
installed server.

6.) wwwconfig-common does not seem to have much in the way of documentation.