On Jul 19, 2016, at 9:52 AM, Ken Cunningham wrote: > You are completely correct, of course - upstream fixes would be ideal, and > much preferred over fixing the portfile to repair upstream deficiencies. Most > ports that use configure already seem to get these things brought in from the > GnuLib replacements, I've found. > > But I suppose I'm torn between what is ideal and what is attainable. I don't > see upstream being responsive to these requests - quite reasonably I guess. > Better things to do than support 8+ year old hardware. Most of these fixes > seem to be added in case-by-case by the individual portfile maintainers. > > These ports are all working for me here. My goal is only to be helpful, and > allow others to share the outcome of my efforts. > > But I can certainly blog the modifications somewhere and let those interested > find it that way, rather than clutter up macports with it, if that is > preferred.
I'm very much in favor of maintaining compatibility with older systems. The MacPorts project doesn't especially want to be in the business of forever maintaining patches to projects, if it can at all be helped. If upstream development has ceased we don't really have much choice but to use our own patches to fix problems, but if the developers still exist, then such matters should be reported to them for fixing, and if you can provide them with a fix that's suitable to be committed to their sources, so much the better. But if you already have working portfiles adding local patches conditionally, that's wonderful, and we can certainly start with that; by all means file MacPorts tickets with your patches. And if upstream does not accept patches to maintain compatibility with older systems, then we can maintain those patches as long as it's practical. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
