wwwconfig-common status

[Penny Leach]

Hi list,

What's the current state of wwwconfig-common? I can't find any
documentation for it, and searching, I found this post:

http://www.mail-archive.com/debian-***@lists.debian.org/msg235114.html

With someone looking for documentation on it and being pointed to lurker
and phpmyadmin. However, neither of those packages seem to depend on it
anymore, and both packages' changelogs reference removing the dependency on
it.

Additionally, it doesn't seem to be mentioned at all in the webapps policy
manual at all.

I apt-got source it and it seems to be just a bunch of shell scripts for
doing stuff. Shall I ignore it completely?

If so, do we not have a way to have common (centrally translateable etc)
templates for asking questions like "what url do you want your new website
to be accessible on" etc, similar to the common templates that
dbconfig-common provide?


Cheers,
Penny

[Penny Leach]

Hi,

wwwconfig-common is used in conjuction with debconf to to setup a
mysql-server
I believe what you are looking for is debconf have a look at
http://www.fifi.org/doc/debconf-doc/tutorial.html

Thanks, I am familiar with debconf.

My problem was that it doesn't seem sensible for every single web
application out there to duplicate the same debconf questions, multiplying
the work for the translators, and being generally inconsistent across
packages.

This seems to be solved for database related questions, by dbconfig-common,
it would seem sensible to do something similar for webapp packaging, or
maybe it's just overkill and every webapp maintainer can continue to write
their own debconf templates.


Cheers,
Penny

[sean finney]

hi penny,

Post by Penny Leach
With someone looking for documentation on it and being pointed to lurker
and phpmyadmin. However, neither of those packages seem to depend on it
anymore, and both packages' changelogs reference removing the dependency on
it.

the way i parsed that, i read "these packages use the 'drop a symlink in
conf.d' method". you'll also see a reply from me in that thread where i
mention a "webapps-common" package, but you'll also notice that that was
something like 2 years (eeks!) ago now.

Post by Penny Leach
I apt-got source it and it seems to be just a bunch of shell scripts for
doing stuff. Shall I ignore it completely?

i'd suggest so.

Post by Penny Leach
If so, do we not have a way to have common (centrally translateable etc)
templates for asking questions like "what url do you want your new website
to be accessible on" etc, similar to the common templates that
dbconfig-common provide?

this was the primary goal of webapps-common (i.e. a parallel to
dbconfig-common). i say "was" because i lost most of my interest in
running this as a pet project on my own and there haven't been any
takers-on for adopting and/or co-maintaining it. there were a couple
folks with some passing level of interest, but maybe once they saw the
(admittedly horrific) code they ran screaming :)

Post by Penny Leach
This seems to be solved for database related questions, by dbconfig-common,
it would seem sensible to do something similar for webapp packaging, or
maybe it's just overkill and every webapp maintainer can continue to write
their own debconf templates.

if you're feeling adventurous, you can try the latest webapps-common from
the svn repo (svn://svn.debian.org/svn/webapps-common/webapps-common/trunk),
which is packaged and i believe is "mostly" working, but the quality and
complexity levels are a bit dubious :) there's some documentation shipped
in the package and it works very similar to dbconfig-common if you're
familiar with that.

but if you want something that will work right now in unstable, you're
probably best off picking an arbitrary subdirectory name, dropping the
apache conf in /etc/<pkg> and symlinking it to /etc/apache2/conf.d/, no
debconf questions asked (or maybe one: "enable this webapp?").

sean

[Penny Leach]

Hi Sean,

Post by sean finney
the way i parsed that, i read "these packages use the 'drop a symlink in
conf.d' method". you'll also see a reply from me in that thread where i
mention a "webapps-common" package, but you'll also notice that that was
something like 2 years (eeks!) ago now.

Ah, I did see your reply as well, but somehow wwwconfig-common and
webapps-common got merged into the same thing in my brain, which is where
the confusion came from.

Post by sean finney
this was the primary goal of webapps-common (i.e. a parallel to
dbconfig-common). i say "was" because i lost most of my interest in
running this as a pet project on my own and there haven't been any
takers-on for adopting and/or co-maintaining it. there were a couple
folks with some passing level of interest, but maybe once they saw the
(admittedly horrific) code they ran screaming :)
if you're feeling adventurous, you can try the latest webapps-common from
the svn repo (svn://svn.debian.org/svn/webapps-common/webapps-common/trunk),
which is packaged and i believe is "mostly" working, but the quality and
complexity levels are a bit dubious :) there's some documentation shipped
in the package and it works very similar to dbconfig-common if you're
familiar with that.

I see... Do you still think that there's a need for webapps-common? Are
you still interested? If there were other people interested in getting
involved would that re-seed your interest?

We have a lot of work to do on the Moodle package at the moment, which may
be a good way to re-work on this. I don't really want to adopt it
completely myself, but we could switch Moodle over to it as a proof of
concept, perhaps, and I could help (and maybe some others on the moodle
package team too, although of course I can't volunteer *for them*)

Post by sean finney
but if you want something that will work right now in unstable, you're
probably best off picking an arbitrary subdirectory name, dropping the
apache conf in /etc/<pkg> and symlinking it to /etc/apache2/conf.d/, no
debconf questions asked (or maybe one: "enable this webapp?").

Yep, definitely dropping into /etc/apache2/conf.d (or better, surely
/etc/apache2/sites-available and then sites-enabled)

But what about "what url do you want your site to live at" for writing a
virtualhost? I don't really like the endpoint being a /webapp directory on
the default hostname... and possibly also ServerAliases or redirects (like
www.sitename should redirect to sitename (or the other way around)).

I can probably get really fancy and think of some other cool options too,
like enabling SSL and other stuff, that is overkill right now but some sort
of consistent approach could work towards.


Cheers,
Penny

[Matt Brown]

Post by sean finney
this was the primary goal of webapps-common (i.e. a parallel to
dbconfig-common).  i say "was" because i lost most of my interest in
running this as a pet project on my own and there haven't been any
takers-on for adopting and/or co-maintaining it.  there were a couple
folks with some passing level of interest, but maybe once they saw the
(admittedly horrific) code they ran screaming :)

One of them may have been me... :)

Post by sean finney
if you're feeling adventurous, you can try the latest webapps-common from
the svn repo (svn://svn.debian.org/svn/webapps-common/webapps-common/trunk),
which is packaged and i believe is "mostly" working, but the quality and
complexity levels are a bit dubious :) there's some documentation shipped
in the package and it works very similar to dbconfig-common if you're
familiar with that.

I see... Do you still think that there's a need for webapps-common?  Are
you still interested?  If there were other people interested in getting
involved would that re-seed your interest?
We have a lot of work to do on the Moodle package at the moment, which may
be a good way to re-work on this.  I don't really want to adopt it
completely myself, but we could switch Moodle over to it as a proof of
concept, perhaps, and I could help (and maybe some others on the moodle
package team too, although of course I can't volunteer *for them*)

The phpwiki package is actually using a fork of the webapps-common
tree from one point in time, there was no package in unstable, so I
just copied the necessary code directly into the postinst, etc scripts
as necessary.

It's been working very nicely for phpwiki for over a year or so now.

I'd certainly be interested in seeing the code make it to a real
package, so that I can remove it from the phpwiki scripts and not have
to maintain it separately, but I can't offer a huge amount of time to
help unfortunately.

Cheers