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