Bug#664761: apache2/conf.d migration: what should webapp packagers do?

[Jonathan Nieder]

Package: apache2
Version: 2.4.1-1
Justification: missing documentation
X-Debbugs-Cc: debian-***@lists.debian.org

Hi,

Upgrading apache2 to the version in experimental breaks my local
gitweb installation. Gitweb ships the following snippet in
/etc/apache2/conf.d/gitweb:

Alias /gitweb /usr/share/gitweb

<Directory /usr/share/gitweb>
Options FollowSymLinks +ExecCGI
AddHandler cgi-script .cgi
DirectoryIndex gitweb.cgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.* /gitweb/gitweb.cgi/$0 [L,PT]
</Directory>

which of course is not supposed to work any more, as described in
NEWS.Debian.gz.

Goals from the gitweb side:

- installing gitweb provides a working gitweb installation out of
the box. The user should not be required to run an a2enconf
command separately.

- customizable by the user, user configuration carried over from
version to version

- upgrades don't silently break it :)

In the new world order, as a packager of a webapp, what should I do
to bring those goals about?

From the PACKAGING file I get the impression that I should rename the

gitweb configuration (with the usual conffile renaming dance) to
/etc/apache2/conf-available/gitweb.conf, depend on an updated apache2,
run

[ -e /usr/share/apache2/apache2-maintscript-helper ] || exit 0
. /usr/share/apache2/apache2-maintscript-helper
apache2_invoke enconf gitweb

in postinst configure, and ask for a Breaks from the apache2
maintainers. Is that right?

This bug report is a request for advice in NEWS.Debian.gz about this,
for example by including a pointer to PACKAGERS in the text and
mentioning whether packages supporting old and new apache at the same
time are possible.

Thanks,
Jonathan

[Paul Wise]

Post by Jonathan Nieder
Upgrading apache2 to the version in experimental breaks my local
gitweb installation.  Gitweb ships the following snippet in
       Alias /gitweb /usr/share/gitweb

That looks like a highly inappropriate thing for gitweb to be doing.
There is no way for the package to know what URL and filesystem paths
(for data/config) the sysadmin wants gitweb to be installed at. The
package needs to ask the sysadmin if they want to setup any instances,
prompt them for the relevant data and run any scripts needed to create
those instances.
--
bye,
pabs

http://wiki.debian.org/PaulWise

[Jonathan Nieder]

(dropping bug#664761 from cc)
Hi Paul,

Post by Paul Wise
That looks like a highly inappropriate thing for gitweb to be doing.

What can I say? It works, and it is a conffile so the sysadmin can

Post by Paul Wise
There is no way for the package to know what URL and filesystem paths
(for data/config) the sysadmin wants gitweb to be installed at. The
package needs to ask the sysadmin if they want to setup any instances,
prompt them for the relevant data and run any scripts needed to create
those instances.

Patches welcome.

Thanks,
Jonathan

[Thijs Kinkhorst]

Post by Jonathan Nieder
(dropping bug#664761 from cc)
Hi Paul,

Post by Paul Wise
That looks like a highly inappropriate thing for gitweb to be doing.

What can I say? It works, and it is a conffile so the sysadmin can

I can say that it seems like a reasonable approach to me.

Most web applications take the following approach: (1) ask whether any and
which webserver should be configured; (2) if apache, add an alias with the
package name. This is also what the webapps policy recommends.

Anything more advanced (specific vhosts, authentication, etc) is probably
highly specific to the local configuration and requires conffile editing
anyway, so it's best to leave that to the admin to decide.

I have noticed that users do expect some default configuration and
activation of the package: when I had a package that just ships an example
Apache config but doesn't install it by default, I got frequent bug
reports about that saying that it's not usable out of the box.

Using "Alias" seems like a good default to configure an application in a
way that it's generically usable, but still easily changable.


Cheers,
Thijs

[Stefan Fritsch]

Post by Paul Wise

Post by Jonathan Nieder
Upgrading apache2 to the version in experimental breaks my local
gitweb installation. Gitweb ships the following snippet in
Alias /gitweb /usr/share/gitweb

That looks like a highly inappropriate thing for gitweb to be
doing. There is no way for the package to know what URL and
filesystem paths (for data/config) the sysadmin wants gitweb to be
installed at. The package needs to ask the sysadmin if they want
to setup any instances, prompt them for the relevant data and run
any scripts needed to create those instances.

I think its not that bad. For a significant part of the users, /gitweb
as urlpath is ok. And the apache config snippet is a conf file, so
changing the URL path is very easy. What is bad is that it is visible
in all vhosts, but that's something we intend to make configurable in
the apache2 2.4 packages.

About the repository paths, those are configured in /etc/gitweb.conf.
I don't think that a web app as simple as gitweb needs to ask things
during installation.