hi pierre,
i'm going to take the step of cc'ing folks who might not be following
this thread but would probably be interested. namely, the debian
maintainers for any "httpd" package[1], php, mysql,
and postgresql.
anyway, i think it's a good idea to distinguish the different areas
that we're trying to address like you have. now, to add more to this
growing document...
On Thu, Aug 19, 2004 at 03:41:34PM +0200, Pierre Habouzit wrote:
> my english was horrible, wasn't it ?
>
> well, I'll try to make a list of what should be unified (I'll use a lot of
> Sean's list, but not only)
>
> (1) DATABASE RELATED
>
> * whether/how to prompt for database usernames/passwords via debconf
> (if necessary), and how not to store the root password.
we could make the package databasename/username/password prompt a low
priority question, and if the user skips those questions, they could be
created automatically with a format something like
$package/debian-$package/$randompw.
> * having a list of available ressource (local or distant)
it wouldn't be too hard to do something like this. get a list
of the installed db servers, previously entered remote servers
from the debconf cache, and finally provide "add a new remote server"
> (2) WEB SERVERS RELATED
>
> * how to get a list of different installed web servers, and how to
> select which ones to target for installation.
again, i think a low priority debconf question would be appropriate.
the question on my mind is, should it default to (when lowest prompt priority
> low) not activating it for any sites, an arbitrary site, or activating
it for all sites?
> * whether/how to include one's configuration with apache. ideally
> there'd be a conf.d style directory, though if the apache folks could
> settle on a name for their config script calling that in postinst would
> work too :)
> * whether/how to restart the web server
and what the default action should be...
> (3) WEB APPS ADMIN RELATED
>
> * fhs-compliant layout for sites, examples of how to seperate the config
> from the rest of the site. what constitutes something that ought to be
> in /var/cache, /var/lib, et c.
i don't think we'd have to go too much into this, since we already have
the fhs to point to, but a few reminders to package maintainers wouldn't
hurt. for example, i upgraded a certain mail-graphing package which
stored some databases in /var/cache, and upon upgrading the package i
lost 3 months of unrecoverable accumulated data.
> * find solution for themeable sites (we don't want the admin to create
> custom files into /usr/share or to patch sites by hand !!!)
this really dips into the software design of the packages themselves,
unfortunately. no reason not to include guidelines though. for example,
i really like the way request-tracker does this[2], but other packages
provide different ways that i think are equally acceptable (like
providing the header/footers as config files, "theme" directories, et c).
> (4) WEB APPS PACKAGING RELATED (aka MISC ;p)
>
> * whether/how to prompt for whether to leave the database after purge
> (or uploaded files, or any local ressource generated by the app)
again and what the default action should be. i think we should get a
general clarification on what policy really says we should do, especially
given all the hoo-hah lately about logfiles being removed on purge.
also, what if the database is remote? tricky...
> * default settings, disallowing default username/passwords for
> web-accessible services.
> * have the possibility to install as a subdirectory of or as a pure vhost
there's no real way to have a clean and automagic vhost install, because
external changes in dns are usually involved. i think what would be
the closest thing we could do would be to provide a sample configuration.
> (5) WEB SCRIPTING LANGAGES RELATED
>
> * php ought to have a php.d directory
> * php PEAR packaging should have a policy
this has been brought up a few times in the past, and it was the
general consensus that there *should* be (similar to how debian
gracefully co-exists with CPAN), but i don't know that anything
further has been done.
sean
[1] grep-available -F Provides -s Maintainer httpd | sed -e 's/[^:]*://' | \
sort | uniq
[2] there's a mirrored directory structure in /usr/local, and if a
corresponding file exists there it is given preference to the
one in /usr/share.
--
Attachment:
signature.asc
Description: Digital signature