olli hauer wrote:
On 2013-01-04 09:51, Scot Hetzel wrote:
On Fri, Jan 4, 2013 at 2:12 AM, Scot Hetzel<swhet...@gmail.com> wrote:
Why am I forced to manualy re-enable all 3rd party modules on each upgrade?
Modules should not disable something that is explicitly enabled by user /
system administrator.
I found the cause of your issue, the www/mod_sendfile/Makefile has
AP_GENPLIST= yes defined. This causes the port to use this code to
create the packing list:
Mk/bsd.apache.mk
451 ap-gen-plist:
452 .if defined(AP_GENPLIST)
453 . if !exists(${PLIST})
454 @${ECHO} "===> Generating apache plist"
455 # apache22
456 @${ECHO} "@unexec ${SED} -i '' -E
'/LoadModule[[:blank:]]+%%AP_NAME%%_module/d'
%D/%%APACHEETCDIR%%/httpd.conf">> ${PLIST}
Found the reason for this sed line, as it is used to remove the
LoadModule line from the httpd.conf file so that when Apache is
uninstalled, the httpd.conf could be removed, if there were no changes
from the original.
see http://svnweb.freebsd.org/ports?view=revision&revision=194395
I still think it is better to disable the module on uninstall, and
enable the module on install.
Hi Scot,
have you also read the commit log?
- Fix leftover httpd.conf for AP_GEN_PLIST using ports. The problem is that
apxs does not remove module line from httpd.conf, it merely comments it out.
Later, on Apache deinstall, the file differs from stock httpd.conf and is not
deleted.
The issue is the following.
In case the LoadModule line is not removed from httpd.conf the port will be
marked as broken by the ports build system.
I'm thinking about an parameter which change the semantic in bsd.apache.mk so
the module can be installed enabled.
For example the following will do that (quick hack)
Index: bsd.apache.mk
===================================================================
--- bsd.apache.mk (revision 309921)
+++ bsd.apache.mk (working copy)
@@ -455,7 +445,11 @@
# apache22
@${ECHO} "@unexec ${SED} -i '' -E '/LoadModule[[:blank:]]+%%AP_NAME%%_module/d'
%D/%%APACHEETCDIR%%/httpd.conf">> ${PLIST}
@${ECHO} "%%APACHEMODDIR%%/%%AP_MODULE%%">> ${PLIST}
+.if defined(AP_MODENABLE)
+ @${ECHO} "@exec %D/sbin/apxs -e -a -n %%AP_NAME%% %D/%F">> ${PLIST}
+.else
@${ECHO} "@exec %D/sbin/apxs -e -A -n %%AP_NAME%% %D/%F">> ${PLIST}
+.endif
@${ECHO} "@unexec echo \"Don't forget to remove all ${MODULENAME}-related directives
in your httpd.conf\"">> ${PLIST}
. endif
.else
According to what was said in previous e-mails, there are several ways
to handle install / deinstall:
1] add #LoadModule line commented on install and remove this line only
if it is still commented (no user change made)
2] do not add anything, print the LoadModule line as pkg-message on
install (this is standard way used by another ports to inform users what
changes must be made to activate some port), do not remove anything on
deinstall, print info message to remove line (similar to @unexec message
above)
3] add LoadModule line uncommented on install (enable modul by default)
and remove the line on uninstall
I prefere second or first variant. Somebody may not be happy to have
modules enabled by default (the same policy as for not enabling services
in rc.conf, not adding cronjobs or changes in periodic.conf)
My first try was to change @unexec sed line to:
@${ECHO} "@unexec ${SED} -i '' -E
'/^#LoadModule[[:blank:]]+%%AP_NAME%%_module/d'
%D/%%APACHEETCDIR%%/httpd.conf" >> ${PLIST}
It will produce following line in +CONTENTS
@unexec /usr/bin/sed -i '' -E
'/^#LoadModule[[:blank:]]+xsendfile_module/d' %D/etc/apache22/httpd.conf
The problem is, that apxs line is working as switch:
@exec %D/sbin/apxs -e -A -n xsendfile %D/%F
First call adds LoadModule line and second removes it. So if the line is
still there on next install, apxs is removing the line instead of left
it untouched.
I don't have time to track it down right know. I will try to investigate
it later today or tomorrow.
Miroslav Lachman
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"