Use of rewriting in a debian package

[Uwe Steinmann]

Hi,

I put together a php application which basically maps the content
of a document management system into a url namespace.
To be more concret: any access to http://localhost/mmc-dms/xxx
has to be mapped on http://localhost/mmc/access.php/xxx
'/mmc' itself is an Alias for /usr/share/mmc/.
I'm currently doing that with rewriting, though there might
be other ways.
Unfortunately this doesn't work with apache2 installed from the
debian package. The reason seems to be the virtual host in
/etc/apache2/sites-enabled/000-default and the rewriting rules
which are put in a seperate file in /etc/apache2/conf.d.
Rewriting rules aren't inherited by virtual hosts and are consequently
unknown.

Question: Is there any way to make the virtual host inherit the
Rewrite rules? I don't want to put 'RewriteOption inherit' into
the virtual host. I'd rather prefer a solution without manual
intervention.

Uwe

[sean finney]

hey uwe,

Post by Uwe Steinmann
Question: Is there any way to make the virtual host inherit the
Rewrite rules? I don't want to put 'RewriteOption inherit' into
the virtual host. I'd rather prefer a solution without manual
intervention.

unfortunately, the only "way" i can think of is to file a bug against to
the apache maintainers asking for a way :(

this is actually one symptom of a larger problem, that being that
there's no way to provide vhost-specific configuration for the
predefined vhost. the webapps-common package will eventually cover this
problem (the virtualhosts it creates have an Include directive pointing
to a vhost-specific location), but this package is still alpha-ish in
nature and i haven't even unleashed it upon experimental.


sean

[Andrew McMillan]

Post by sean finney
hey uwe,

Post by Uwe Steinmann
Question: Is there any way to make the virtual host inherit the
Rewrite rules? I don't want to put 'RewriteOption inherit' into
the virtual host. I'd rather prefer a solution without manual
intervention.

unfortunately, the only "way" i can think of is to file a bug against to
the apache maintainers asking for a way :(
this is actually one symptom of a larger problem, that being that
there's no way to provide vhost-specific configuration for the
predefined vhost. the webapps-common package will eventually cover this
problem (the virtualhosts it creates have an Include directive pointing
to a vhost-specific location), but this package is still alpha-ish in
nature and i haven't even unleashed it upon experimental.

Hola Sean!

The fact that it includes stuff to support such a situation suggests
that it should _not_ be put into experimental, it should be unleashed
upon 'unstable' immediately.

I seem to recall discussing this at Debconf6 and that even Manoj was of
the opinion that this should happen. Now. Well, then, actually, since
that was back in May...

When can we look forward to a release which we can usably depend on, and
which we can all improve in parallel, rather than waiting on your
solitary search for perfection.

:^)
Andrew.

-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: [phone] MOB: +64(272)DEBIAN OFFICE: [phone]
Chicken Little was right.
-------------------------------------------------------------------------

[sean finney]

hey andrew,

Post by Andrew McMillan
The fact that it includes stuff to support such a situation suggests
that it should _not_ be put into experimental, it should be unleashed
upon 'unstable' immediately.

the biggest inhibitor lately is that i have a really, really full plate
right now with my other debian stuff, so i haven't had much time to
devote to it.

Post by Andrew McMillan
When can we look forward to a release which we can usably depend on, and
which we can all improve in parallel, rather than waiting on your
solitary search for perfection.

well, for the "improving in parallel" part of that, it *is* in an svn
repository, after all :) if more people were interested in using it
(and ideally helping develop/maintain it) i don't have a problem with
unleashing it on unstable as long as there's an agreement that i don't
want it in etch. at least until it's had a chance to prove itself, the
"api" and behaviour stabilize, bugs are shaken out, etc. but i'd rather
assume that it's not going to be in etch, which de-stresses me a bit and
lets me keep priorities straight on the stuff i do want to get done
before etch goes out the door.


sean

[Andrew McMillan]

Post by sean finney
hey andrew,
the biggest inhibitor lately is that i have a really, really full plate
right now with my other debian stuff, so i haven't had much time to
devote to it.

I can completely understand :-)

Post by sean finney

Post by Andrew McMillan
When can we look forward to a release which we can usably depend on, and
which we can all improve in parallel, rather than waiting on your
solitary search for perfection.

well, for the "improving in parallel" part of that, it *is* in an svn
repository, after all :) if more people were interested in using it
(and ideally helping develop/maintain it) i don't have a problem with
unleashing it on unstable as long as there's an agreement that i don't
want it in etch. at least until it's had a chance to prove itself, the
"api" and behaviour stabilize, bugs are shaken out, etc. but i'd rather
assume that it's not going to be in etch, which de-stresses me a bit and
lets me keep priorities straight on the stuff i do want to get done
before etch goes out the door.

Why not put it in unstable and immediately file an RC bug against it to
keep it out of Etch?

Or an e-mail to the release managers might provide (or be) an easier
solution still.

I would far rather depend on a warts-and-all copy that was in a standard
repository than depend on a bleeding-edge copy in my own repository. Of
course if I use it for my own applications and then expect to install
them on Etch I would have to do that, but I would be likely to want to
sync the unstable version on there in any case.

Putting it in unstable is worlds better than putting it in experimental
in any case. Experimental is much more suited to packages which are
major new releases of _existing_ applications which everyone depends on.
Putting a new package into unstable which is flawed just means that
people won't depend on it yet, and it might mean that some of them will
fix a few problems if the working features make it a worthwhile
proposition.

Cheers,
Andrew.

-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: [phone] MOB: +64(272)DEBIAN OFFICE: [phone]
Open Source: the difference between trust and antitrust
-------------------------------------------------------------------------

[Uwe Steinmann]

Post by sean finney
hey uwe,

Post by Uwe Steinmann
Question: Is there any way to make the virtual host inherit the
Rewrite rules? I don't want to put 'RewriteOption inherit' into
the virtual host. I'd rather prefer a solution without manual
intervention.

unfortunately, the only "way" i can think of is to file a bug against to
the apache maintainers asking for a way :(
this is actually one symptom of a larger problem, that being that
there's no way to provide vhost-specific configuration for the
predefined vhost. the webapps-common package will eventually cover this
problem (the virtualhosts it creates have an Include directive pointing
to a vhost-specific location), but this package is still alpha-ish in
nature and i haven't even unleashed it upon experimental.

Thanks for the reply, though there seems to be currently no
other solution than manual editing.

Uwe