Bug 116984 - [patch] www/apache13-modssl missing perl5.8 as RUN_DEPENDS
Summary: [patch] www/apache13-modssl missing perl5.8 as RUN_DEPENDS
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-apache (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-06 23:00 UTC by Cory R. King
Modified: 2011-06-20 21:33 UTC (History)
1 user (show)

See Also:


Attachments
Makefile.patch (790 bytes, patch)
2007-10-06 23:00 UTC, Cory R. King
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Cory R. King 2007-10-06 23:00:03 UTC
This ports is missing perl as a run dependancy.  APXS is actually a perl script, and I think apachectl is as well.

Fix: mark perl as a run dependancy, not just a build dep.
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.
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2007-10-06 23:00:12 UTC
Responsible Changed
From-To: freebsd-ports-bugs->dinoex

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 Dirk Meyer freebsd_committer freebsd_triage 2007-10-09 13:05:07 UTC
State Changed
From-To: open->feedback


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
Comment 3 Cory R. King 2007-10-09 22:15:56 UTC
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
Comment 4 dirk.meyer 2007-10-16 19:29:47 UTC
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/
Comment 5 dfilter service freebsd_committer freebsd_triage 2008-01-17 10:15:24 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"
Comment 6 Dirk Meyer freebsd_committer freebsd_triage 2008-01-22 14:07:44 UTC
State Changed
From-To: feedback->patched

- local fix committed
Comment 7 Philip M. Gollucci freebsd_committer freebsd_triage 2009-05-13 07:06:56 UTC
Responsible Changed
From-To: dinoex->apache

Over to maintainer.
Comment 8 Olli Hauer freebsd_committer freebsd_triage 2011-06-20 21:32:37 UTC
State Changed
From-To: patched->closed

Patch was committed in Makefile rev 1.186