fastcgi port fixed but not updated?

[Lowell Gilbert]

Mike Friedman <mikef at ack.Berkeley.EDU> writes:

> On Tue, 26 Jul 2005 at 17:10 (-0400), Lowell Gilbert wrote:
> 
> > Mike Friedman <mikef at ack.Berkeley.EDU> writes:
> >
> >> I've recently discovered a problem report for the mod_fastcgi
> >> (2.4.2) port:
> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/79774. The report
> >> seems to indicate that the port was fixed shortly after the PR was
> >> sent (May 31), yet I just did a cvsup and the buggy port still
> >> shows up.
> >>
> >> ...
> >>
> >> Anyone know what might be going on?  Since the fastcgi port is
> >> called by the rt-3.4.2 port (which is my real interest), keeping my
> >> fixed version of the former around under a different name is not
> >> really a good option, in case I need to update RT.
> >
> > The bug report claims that the install fails. It works fine for me
> > with the Apache 1.3 port, so I suspect that a more sophisticated fix
> > would be needed; if the path were hard-coded as you suggest, the
> > port would *only* work with Apache2.
> 
> Lowell,
> 
> I can see your point about the content of the fix.  But the bug report
> does say the following (in the Audit-Trail):
> 
>     Port has been updated since this PR has been sent.
>     It seems to install flawlessly.
> 
> As you say, the one line fix (in 'do-install') would not seem
> consistent with your experience installing fastcgi with Apache 1.3,
> where you don't have the problem.  (I'm installing RT with fastcgi and
> Apache 2). Just looking at the Makefile didn't reveal to me that the
> fix proposed in the bug report wouldn't be appropriate for Apache 1.3.
> 
> But my question was motivated by the apparent contradiction between
> the above-quoted statement in the report and the fact that the port
> wasn't actually updated (perhaps for the reason you give).
> 
> Meanwhile, I'm left with a mod_fastcgi port that will not install, as
> delivered, with Apache 2.  Yet the RT port depends on the fastcgi port.

Yep.  Your problem is actually different than the one in the PR.

I suggest filing a new PR; preferably with a committable fix.