py26-numpy at 1.12.0_0+gfortran build fails on 10.11

[Richard L. Hamilton]

> On Jan 23, 2017, at 08:40, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> 
>> On Jan 23, 2017, at 07:36, Richard L. Hamilton <rlhamil at smart.net> wrote:
>> 
>> Thanks - now it's no longer trying to update to an unsupported version.
>> 
>> For those newly installing the package (whether from source or binary), would it be possible to have (the Portfile?) provide an install-time message warning that there are no further upstream updates expected past 1.11.3?  While there can be occasional needs for old versions, people should probably be reminded when they're unsupported, so that they can evaluate the need vs risk of un-patched security issues.
> 
> There are many other ports in MacPorts (including other python modules and php modules) that provide old versions that are no longer updated, and we don't have a mechanism in place to notify users of any of that.
> 
> We could use the "notes" mechanism to add a note to those ports. Of course, users who already have the latest version of the software installed will never see that note. Only users who initially install that software, or upgrade to that version, will see it, or users who manually decide to run "port notes" on that port. So I'm not sure how useful this would be.
> 

I'm not suggesting going back and changing all the existing ones, certainly not unless there's an easy way to FIND all the ports that are like that.  However, as new situations come up, I wonder if it might not be a bad idea if there were guidance that when it's realized that a version is the final (upstream) version, the port include such a warning, perhaps including the warning that such warnings may not be provided for all existing ports, and even if provided, can only be displayed as you describe, for installed ports.  Individual existing port versions could be changed accordingly (with an incremented _# suffix, I suppose) if people noticed the applicability and reported them...or not.

Any increased encouragement to alertness may be better than none, even if it's far from comprehensive. :-)  I won't go so far as to use the rather weak "if it saves even one, it's worth it" argument, merely to speculate that if it saves some non-zero number, it MAY be worth it.

If there's not an easy way to find ports like that, perhaps there should also be a way to tag ports like that, so they may be easily found in the future; and there may even be some other utility to being able to spot those - if it were me in your shoes, I might also want a field for the release date of the upstream version, so that with those two fields, there might eventually be the option of a policy to remove really old stale ports like that.  However, if that requires new metadata fields, I suppose that's a longer-term possibility.

I strongly suspect some sites have a policy that only software being actively maintained be present on their systems - or that they at least make some effort to be aware of exceptions.  That's not totally assured even for a port that is being updated upstream (if the port has no maintainer and nobody mentions the lack of a recent update).  But every step closer alleviates concerns, and even a newly adopted practice of alerting to such ports might improve support of such a policy going forward.  I do know that some sites are perversely MORE paranoid about open source (where, aside from issues such as Ken Thompson's "Reflections on Trusting Trust", one can look at the source and at least know more than if one only had binaries) than about fairly stale closed-source software, although they may have instituted a one-time "it's maintained or it's gone" review in preparation for Y2K, that perversely didn't even include exceptions for programs that could clearly be shown not to have Y2K issues.  (Been there, done that; one of 'em was too useful to lose, so I saved the source, inspected it thoroughly, and recompiled the darn thing post-Y2K.)