Hi,

On Tuesday 13 January 2009, Stefan Fritsch wrote:
> BTW, apache 1.3 is not in lenny. Maybe the 1.3 specific parts can be
> removed?

this is a step, I scheduled for post lenny. The actual package allows also to be
installed on etch.

> On Tuesday 13 January 2009, Adeodato Simó wrote:
> > (Apache2 maintainers, CC'ed, context is #511293.)
> >
> >   elif [ -f /usr/lib/$webserver/modules/libphp5.so ]; then
> >       a2enmod php5
> >   fi

Okay ... looks much better.

> > Though if this is indeed the intended way to use it, let's see if
> > the apache2 maintainers have any comments.
>
> The question is if there is actually a good reason for ipplan's
> postinst to do that. If libapache2-mod-php5 is pulled in by the
> dependencies, its postinst will activate mod_php in apache2 and
> ipplan doesn't need to do anything. If php5 is already installed but
> is not enabled, the admin has manually disabled it and probably had
> some reason for that. I don't think ipplan should restore the
> symlink.
>
> If you add it, a2enmod is preferred.
>
> For mod_actions and mod_cgi, it is less obvious what ipplan's postinst
> should do. I guess both ways are acceptable.

I switched to a2enmod ... and yes, it seems to be much better to drop enabling
the php modul. For lenny I would keep the behavior, post lenny I think I will
drop the php part.

--- debian/ipplan/trunk/debian/postinst (revision 1197)
+++ debian/ipplan/trunk/debian/postinst (revision 1648)
@@ -45,19 +45,13 @@
            apache2)
                if [ -d /etc/$webserver/mods-enabled ]; then
-                   if [ ! -f /etc/$webserver/mods-enabled/actions.load -a ! -h 
/etc/$webserver/mods-enabled/actions.load ]; then
-                       ln -s /etc/$webserver/mods-available/actions.load 
/etc/$webserver/mods-enabled/actions.load
+                   if [ -f /usr/lib/$webserver/modules/mod_actions ]; then
+                       a2enmod actions >/dev/null
                    fi
-                   if [ -f /etc/apache2/mods-available/php4.load ]; then
-                       if [ ! -f /etc/$webserver/mods-enabled/php4.load -a ! 
-h /etc/$webserver/mods-enabled/php4.load ]; then
-                           ln -s /etc/$webserver/mods-available/php4.load 
/etc/$webserver/mods-enabled/php4.load
-                       fi
-                   elif [ -f /etc/apache2/mods-available/php5.load ]; then
-                       if [ ! -f /etc/$webserver/mods-enabled/php5.load -a ! 
-h /etc/$webserver/mods-enabled/php5.load ]; then
-                           ln -s /etc/$webserver/mods-available/php5.load 
/etc/$webserver/mods-enabled/php5.load
-                       fi
+                   if [ -f /usr/lib/$webserver/modules/libphp4.so ]; then
+                       a2enmod php4 >/dev/null
+                   elif [ -f /usr/lib/$webserver/modules/libphp5.so ]; then
+                       a2enmod php5 >/dev/null
                    else
-                       if [ ! -f /etc/$webserver/mods-enabled/cgi.load -a ! -h 
/etc/$webserver/mods-enabled/cgi.load ]; then
-                           ln -s /etc/$webserver/mods-available/cgi.load 
/etc/$webserver/mods-enabled/cgi.load
-                       fi
+                       a2enmod cgi >/dev/null
                    fi
                fi

Any objections?

> In any case, defining what webapps and apache modules should do in
> their maintainer scripts is definitely a project for squeeze.

Yes, a best practice / policy would be appreciated.

Thanks and with kind regards, Jan.

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to