On Mon, Apr 19, 2004 at 01:59:49PM +0200, Martin Pitt wrote:
> AFAIK when listing it as a conffile, it had to be present in the deb
> and thus would be installed unconditionally. But since previous
> fibusql versions had to be configured manually in httpd.conf (there
> was no conf.d/), I don't want to install the conffile for upgrading
> users.
>
> Since this seems to cause a lot of questions and confusion, is there
> something like a 'Debian web applications packaging howto"? When
> looking at the bug list of the original post, it seems necessary.
yeah, i think "11.5 Web servers and applications" is in need of an
update/clarification on this. i think if it were included as a conffile
it should be disabled by default, or if using something similar to your
scheme a debconf question would be appropriate. the real question is
what's the Right Way to do this? i've seen many different approaches,
some of which have made my skin crawl (like by default activating a web
app with a login/pass of admin/admin, manually mucking with httpd.conf,
et c, et c)
in an ideal world, i would hope that policy provide:
- classification of different kinds of web apps
- does it require login/pass?
- does it expose sensitive information?
- can/should it be activated automatically at
installation?
- server agnostic tools for installation et c
- the work that the apache folks are doing is great, but
in the debian tradition (i.e.: update-rc.d), i think
using wwwconfig-common with hooks to this and
possibly other alternate web server configuration
tools would be ideal[1].
- how to determine the Depends: field and other misc. packaging
issues:
- what apps should depend on httpd?
- what apps should depend on apache*?
- what's the most maintainable way to determine what
web servers are installed on a system during
installation/configuration[2]?
- what's the most maintainable way to prompt the user
for on what web servers the application should be
installed[2]?
- dh_webapp?
sean
[1] of course this begs the question: how many users are actually using
these other servers, and how much interest is there in catering
to them?
[2] i guess what i'm getting at here is having centralized
scripts/templates would prevent the need for future mass bug filing
Attachment:
signature.asc
Description: Digital signature