[129391] trunk/dports/perl/p5-cgi-speedycgi/Portfile

[David Evans]

On 12/12/14 11:12 PM, Mojca Miklavec wrote:
> On Fri, Dec 12, 2014 at 10:38 PM, David Evans wrote:
>> On 12/12/14 11:54 AM, Ryan Schmidt wrote:
>>>> On Dec 12, 2014, at 8:49 AM, mojca at macports.org wrote:
>>>>
>>>> @@ -1,10 +1,13 @@
>>>>    # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
>>>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>>>>    # $Id$
>>>>    +# Port is broken:
>>>> +# - http://trac.macports.org/ticket/33479
>>>> +
>>>>    PortSystem          1.0
>>>>    PortGroup           perl5 1.0
>>>>    -perl5.branches      5.10 5.12 5.14 5.16
>>>> +perl5.branches      5.10 5.12 5.14 5.16 5.18 5.20
>>> I don't understand this change. If we're adding perl branches without
>>> testing that they work, then let's just do that for all the remaining perl
>>> module ports all at once, as was suggested in months past. I had wanted to
>>> avoid that, because I like our standing policy of verifying that a port
>>> builds before committing a change. If we're not going to do that here, then
>>> there's no reason to do each port separately.
>> I agree with Ryan.  While it would be easy to do a bulk change on the
>> remaining ports that do not support 5.18 5.20, if a known issue exists with
>> a particular port then it should be fixed before making the update.
> I'm sorry for this change, but I have another question.
>
> Assuming that all the working ports have been taken care of: what
> would you do with completely broken ports (that is: ports where
> p5.16-foo is just as broken as p5.20-foo)? Obviously we are not
> removing the existing broken variants. (I removed broken variants
> 5.8-5.14 in p5-wx for example, but there 5.16 worked just fine.)
>
> Mojca
>
If a port is completely broken and it's agreed that there is no hope of 
fixing it, I would vote to remove it.

p5-cgi-speedycgi may be such a port as it really does appear to be 
completely broken and has not been updated since 2003.  Ignoring the 
fact that CGI in general is a bit outdated, there are other, perhaps 
better, ways to accomplish similar goals (e.g. mod_fcgid, mod_fastcgi, 
mod_perl2).

Dave