hey!
On Tue, May 03, 2005 at 12:32:38PM +0200, Alexis Sukrieh wrote:
> To start with, we have to list the main common issues a webapp
> maintainer can face.
how about that plus what a "local admin" can experience based
on how a webapp is packaged.
> I suggest that we discuss on this list every issue, the idea is to
> gather points of view and solutions on each of them.
sure.
> Handling param files which are editable through a web interface
> -----------------------------------------------------------------
>
> Most of the time, webapps come with a couple of configuration files
> which are handled through a web admin area.
>
> * Those files should be considered conffiles and thus be located under
> /etc/$package. Note that the file must be writable by www-data.
i think that this disputable.
> Handling template files
> -----------------------------------------------------------------
> In a way, some users would like to see them as conffiles in order to
> keep their local changes when upgrading.
that's a world of pain, man.
> * One solution I like is to provide a default template directory,
> notifying the user in README.Debian (or in a debconf note) that he must
> not touch it and provide a way to use template from an alternate point.
> This solution seems to be used in some packages.
i think this isn't really a packaging issue as much as it's an upstream
developer issue. some authors, notably best-practical (request-tracker)
provide a really easy way to do this, which is great. others don't,
but i don't think there should be any requirement.
however, there should be a way for the local admin to override whatever
is overridable, whether it be the template files, themes, or
stylesheets.
> Configuring the package when the database server is not running
> -----------------------------------------------------------------
> Creating/updating a database account for the web application
> -----------------------------------------------------------------
i think i have both of these covered in dbconfig-common. the very first
thing you're asked is "do you want to do this automatically or manually?",
so if the db server is down the admin can say "no thank you" and install
it later manually. otherwise, if the server is down and it tries it
will fail the install as gracefully as possible, giving the admin the
chance to reinstall the package.
> Providing a VirtualHosting facility
> -----------------------------------------------------------------
>
> On some occasions, system adminstrations need to run different versions
> of a webapp package, as they are used across different virtualhosts.
> It's usually quite hard to do that currently. Most packages can only
> have one version installed at a time.
> You will probably need to fetch the packages' source and do a lot of
> modifications
>
> * The standard approach is to install stuff from source.
> * Another way to do that is to bump the package name but that seems to
> be a solution that's not well liked by some DDs
virtual hosting will be a fairly complicated thing to approach. most
applications *do* work in such an environment, but it involves tweaking
of configuration files in a non-intuitive way. for example, with a php
app, you can do something like this in your config.php:
<?php
if($_GLOBALS['HTTP_SERVERNAME'] == "onehostname.com") {
// ^ or whatever that variable is, i forget it off the top of my head
$dbuser="foo"
$dbpass="bar"
} else {
$dbuser="far"
$dbpass="sar"
}
however, that also means supporting multiple databases, which is a
little trickier to do.
anyway, getting a back on track, i think a web application must work
both under a subdirectory and in a virtual host environment, which isn't
asking a lot and i don't know of any that can't be fanagled to work in
both.
okay, here's a few more:
- registering your application with the web server
- unregistering your application with the web server
- registering your php library with the php install
- unregistering your php library with the php install
- placement of static web content
- placement of dynamic web content
- is cgi-bin obsoleted?
also, it's worth taking a look at what notes i already have written
down in my web policy outline[1].
sean
[1] http://people.debian.org/~seanius/policy/webapp-policy.html
--
Attachment:
signature.asc
Description: Digital signature