> > * 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.
the fact is if you change some templates, you don't want the upgrade to
simply override them.
and AFAIK, rt is not that good, since it has no less than 3 packages in
debian, and I recall some guy explaining that it was really hard to
upgrade from one version to the next, and that was why there is 3
packages (v3, 3.2 and 3.4). IMHO, that is not a success story at all.
if every single webapp means a new package for each new minor
release ... we are driving into the wall.
> > 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.
not really. most of the time, web apps have a separate config file. the
only thing that you need, is to play with symlinks from /srv. that is
really possible (in fact I do it by hand on my machines, so I'm sure of
it).
IMHO, this is often possible to provide some :
srv-instanciate [webapp] [directory]
that would work like that :
srv-instanciate myApp /srv/myvhost.mydomain.org/myapp
and that would :
* create all the required symlinks needed in order that the app would
work
* would create a conffile e.g. in /etc/myapp/myvhost.mydomain.org.conf
that would be symlinked from the right place
in /srv/myvhost.mydomain.org/myapp [1]
* register this beeing attached to the virtual host, what is what you
suggest
> - 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
IMHO, we should :
- (ur)register vhosts with the web server
- (un)register apps with vhosts
- let the php libraries live in a subdirectory of /usr/share/php and
let it be in the include_path
and then , "the good way" of handling templates is trivial : the user
only has to delete the symlinks to the default templates dir, and put
his own content here. that would not be deleted/overwriten by upgrades,
and would also be OK. and for the clever apps (like rt may do up to a
point) that are able to upgrade templates, I believe that the
maintainer should be able to do run the upgrade scripts automagically
too.
I know this is a lot of things to write, but those problems are sooooooo
common in web apps, that this would be a really well used and well
shared code.
> - is cgi-bin obsoleted?
I don't think so, for PHP, I've been told fastcgi is more efficient than
apache module e.g. But that is sth the webapp should not have to be
aware of. most of (even if it's not 100% true) the web apps (in php at
least) work in php-mod as well as in cgi mode. so that should be sth
that only the webserver has to be aware of.
[1] this is already what most of web apps do for the single default
instance, so it's really sensible
--
·O· Pierre Habouzit
··O
OOO http://www.madism.org
Attachment:
pgpqhYDpYicx0.pgp
Description: PGP signature