From coryking@xlan.org  Sat Oct  6 21:53:41 2007
Return-Path: <coryking@xlan.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id AC96616A46D
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  6 Oct 2007 21:53:41 +0000 (UTC)
	(envelope-from coryking@xlan.org)
Received: from strongbad.xlan.org (strongbad.xlan.org [216.127.55.72])
	by mx1.freebsd.org (Postfix) with ESMTP id 9889613C480
	for <FreeBSD-gnats-submit@freebsd.org>; Sat,  6 Oct 2007 21:53:41 +0000 (UTC)
	(envelope-from coryking@xlan.org)
Received: from coryhome1.xlan.org (207-178-4-25.wia.com [207.178.4.25])
	by strongbad.xlan.org (Postfix) with ESMTP id BD07150;
	Sat,  6 Oct 2007 14:36:02 -0700 (PDT)
Received: by coryhome1.xlan.org (Postfix, from userid 1003)
	id 9890F11514; Sat,  6 Oct 2007 14:35:57 -0700 (PDT)
Message-Id: <20071006213557.9890F11514@coryhome1.xlan.org>
Date: Sat,  6 Oct 2007 14:35:57 -0700 (PDT)
From: Cory R. King <coryking@mozimedia.com>
Reply-To: Cory R. King <coryking@mozimedia.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc: coryking@mozimedia.com
Subject: [patch] www/apache13-modssl missing perl5.8 as RUN_DEPENDS
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         116984
>Category:       ports
>Synopsis:       [patch] www/apache13-modssl missing perl5.8 as RUN_DEPENDS
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    apache
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Oct 06 22:00:03 GMT 2007
>Closed-Date:    Mon Jun 20 20:33:32 UTC 2011
>Last-Modified:  Mon Jun 20 20:33:32 UTC 2011
>Originator:     Cory R. King <coryking@mozimedia.com>
>Release:        FreeBSD 6.2-RELEASE-p3 i386
>Organization:
Mozi Media Group, LLC.
>Environment:
System: FreeBSD compiler.local 6.2-RELEASE-p3 FreeBSD 6.2-RELEASE-p3 #2: Sat Apr 14 15:51:51 PDT 2007 root@compiler.mozimedia.local:/mnt/binaries/obj/usr/src/sys/CORE2_62VM i386

>Description:
This ports is missing perl as a run dependancy.  APXS is actually a perl script, and I think apachectl is as well.

>How-To-Repeat:
You have to use a system like tinderbox that cleans out packages between each step.  This bug was probably never found because on a real system
we all have perl5 installed anyway and pointyhat never builds www/mod_* using this as an APACHE_PORT.

1) Compile www/apache13-modssl with any flags (I was using MOD_DEFLATE)
2) Compile something like mod_dav or mod_gzip and make sure they are building against this port for their APACHE_PORT.  

Under a system like tinderbox that guts out all the packages between builds, modules that rely on apxs to do their magic will fail because apxs wants perl, 
specifically /usr/local/bin/perl.

>Fix:
mark perl as a run dependancy, not just a build dep.

--- Makefile.patch begins here ---
? Makefile.patch
Index: Makefile
===================================================================
RCS file: /home/ncvs/ports/www/apache13-modssl/Makefile,v
retrieving revision 1.184
diff -u -r1.184 Makefile
--- Makefile	16 Sep 2007 20:05:48 -0000	1.184
+++ Makefile	6 Oct 2007 21:22:37 -0000
@@ -7,7 +7,7 @@
 
 PORTNAME=	apache+mod_ssl
 PORTVERSION=	${VERSION_APACHE}+${VERSION_MODSSL}
-PORTREVISION?=	0
+PORTREVISION?=	1
 CATEGORIES?=	www security
 MASTER_SITES=	${MASTER_SITE_APACHE_HTTPD} \
 		${MASTER_SITES_MODSSL:S/$/:mod_ssl/} \
@@ -43,7 +43,7 @@
 VERSION_MODDEFLATE=	1.0.21
 USE_OPENSSL=	yes
 HAS_CONFIGURE=	yes
-USE_PERL5_BUILD=	yes
+USE_PERL5=	yes
 MASTER_SITES_MODSSL=	http://www.modssl.org/source/ \
 		ftp://ftp.modssl.org/source/ \
 		ftp://ftp.blatzheim.com/pub/mod_ssl/ \
--- Makefile.patch ends here ---


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-ports-bugs->dinoex 
Responsible-Changed-By: edwin 
Responsible-Changed-When: Sat Oct 6 22:00:12 UTC 2007 
Responsible-Changed-Why:  
Over to maintainer (via the GNATS Auto Assign Tool) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=116984 
State-Changed-From-To: open->feedback 
State-Changed-By: dinoex 
State-Changed-When: Tue Oct 9 14:05:07 CEST 2007 
State-Changed-Why:  

It is possible to run apache with modules on a system without perl. 

$ file `which apachectl` 
/usr/local/sbin/apachectl: Bourne shell script text executable 

I would like to change the apache-modssl port to force perl at runtime. 

Checking the modules I use, some need perl at buildtime only 
and therefor they have set: 
USE_PERL5_BUILD=        yes 

e.G. 
ports/www/mod_ruby/Makefile 


http://www.freebsd.org/cgi/query-pr.cgi?pr=116984 

From: "Cory R. King" <coryking@mozimedia.com>
To: <bug-followup@FreeBSD.org>,
	<coryking@mozimedia.com>
Cc:  
Subject: Re: ports/116984: [patch] www/apache13-modssl missing perl5.8 as RUN_DEPENDS
Date: Tue, 9 Oct 2007 14:15:56 -0700

 Hello Dinoex,
 
 Apxs is perl, and while I'm following you that it is a build dependency,
 here is the scenario where I run into trouble:
 
 1) Build apache13-modssl inside a clean jail
 2) make it a package.
 3) tinderbuild now tries to build mod_gzip/mod_dav inside a freshly cleaned
 jail
 4) tinderbuild looks at the build depends mod_gzip, which is only
 apache13-modssl.
 5) tinderbuild adds apache13-modssl via pkg_add which pulls in all of
 apache13's run_depends.
 6) mod_gzip blows up and dies during it's config stage because it cannot run
 apxs.
 
 
 Now I follow what you are saying, apache itself doesn't need perl to run,
 but apxs needs it to run.  The question is, yes apxs is only used for
 building apache modules, but in a way, it is a "runtime program" just like
 httpd?  I'd argue the modules shouldn't need to register perl as a build
 dependency unless they themselves are using it.  How would they know if apxs
 is perl? What if someday somebody makes apxs a compiled c program or starts
 using ruby?
 
 I can also see the argument that unless you are module building, there is no
 reason to pull in dependencies that aren't really needed.  This is probably
 very true on embedded systems that don't have any need for perl.
  
 Dunno...  maybe make it a knob like WITH_APXS that installs apxs and
 registers perl as a RUN_DEPENDS?  If they don't use the knob, maybe warn
 them "hey, you will not be able to build modules without WITH_APXS".  Heck,
 you could even pitch it as some kind of security feature :-)
 
 ... I haven't even looked but is apache2 using perl for its apxs?  How do
 they handle it?
 
 Further, am I an idiot?  Is there something I'm missing in bsd.apache.mk
 that lets me build apache13-modssl and have the makefiles automagically pull
 in mod_perl, mod_gzip & mod_dav?
 
 Thanks!
 
 --
 Cory R. King
 Mozi Media Group, LLC.
 http://www.mozimedia.com
 
 

From: dirk.meyer@dinoex.sub.org (Dirk Meyer)
To: FreeBSD-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: ports/116984: [patch] www/apache13-modssl missing
	perl5.8 as RUN_DEPENDS
Date: Tue, 16 Oct 2007 20:29:47 +0200

 Cory R. King schrieb:,
 
 >  Apxs is perl, and while I'm following you that it is a build dependency,
 >  here is the scenario where I run into trouble:
 >  [...]
 >  6) mod_gzip blows up and dies during it's config stage because it cannot run
 >  apxs.
 
 Right, it blows in "Build" stage, not in "Run" stage.
 
 >  Now I follow what you are saying, apache itself doesn't need perl to run,
 >  but apxs needs it to run.  The question is, yes apxs is only used for
 >  building apache modules, but in a way, it is a "runtime program" just like
 >  httpd?  I'd argue the modules shouldn't need to register perl as a build
 >  dependency unless they themselves are using it.  How would they know if apxs
 >  is perl? What if someday somebody makes apxs a compiled c program or starts
 >  using ruby?
 >
 >  I can also see the argument that unless you are module building, there is no
 >  reason to pull in dependencies that aren't really needed.  This is probably
 >  very true on embedded systems that don't have any need for perl.
 >   
 >  Dunno...  maybe make it a knob like WITH_APXS that installs apxs and
 >  registers perl as a RUN_DEPENDS?  If they don't use the knob, maybe warn
 >  them "hey, you will not be able to build modules without WITH_APXS".  Heck,
 >  you could even pitch it as some kind of security feature :-)
 
 I agree that a knob in bsd.apache.mk would be the best soultion.
 
 >  ... I haven't even looked but is apache2 using perl for its apxs?  How do
 >  they handle it?
 
 Same issue there.
 
 >  Further, am I an idiot?  Is there something I'm missing in bsd.apache.mk
 >  that lets me build apache13-modssl and have the makefiles automagically pull
 >  in mod_perl, mod_gzip & mod_dav?
 
 At the moment there is no way a port can "inherit" BUILD_DEPENDS from
 its dependency. Using RUN_DEPENDS for this itself is an ugly hack.
 It was introduced to base apache13 port, but it make upgrading
 a production system much more time-consuming and error-prone.
 
 
 kind regards Dirk
 
 - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany
 - [dirk.meyer@dinoex.sub.org],[dirk.meyer@guug.de],[dinoex@FreeBSD.org]
 http://people.freebsd.org/~dinoex/errorlogs/

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: ports/116984: commit references a PR
Date: Thu, 17 Jan 2008 10:15:24 +0000 (UTC)

 dinoex      2008-01-17 10:15:15 UTC
 
   FreeBSD ports repository
 
   Modified files:
     www/apache13-modssl  Makefile 
   Log:
   - new option WITH_PERL
   workaround till global solution in bsd.apache.mk
   PR:             118647, 116984
   
   Revision  Changes    Path
   1.186     +4 -0      ports/www/apache13-modssl/Makefile
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: feedback->patched 
State-Changed-By: dinoex 
State-Changed-When: Tue Jan 22 15:07:44 CET 2008 
State-Changed-Why:  
- local fix committed 

http://www.freebsd.org/cgi/query-pr.cgi?pr=116984 
Responsible-Changed-From-To: dinoex->apache 
Responsible-Changed-By: pgollucci 
Responsible-Changed-When: Wed May 13 06:06:56 UTC 2009 
Responsible-Changed-Why:  
Over to maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=116984 
State-Changed-From-To: patched->closed 
State-Changed-By: ohauer 
State-Changed-When: Mon Jun 20 20:32:37 UTC 2011 
State-Changed-Why:  
Patch was committed in Makefile rev 1.186 

http://www.freebsd.org/cgi/query-pr.cgi?pr=116984 
>Unformatted:
