For you or anybody else misunderstanding my above posts, as
@barracuda156 states, it is certainly not a pointless endeavour. Just an ongoing battle that you are waging constantly with people who care very little about PowerPC big endian Mac platforms. There are a few others, also on the Linux side that are in the same boat (Rene Rebe of T2SDE for example). People that are constantly finding and discovering fixes and providing support for vintage and retro platforms but get little acknowledgment or support from upstream - even fixes that are sent upstream are often ignored for years. There are numerous cases where PowerPC support is just deleted ‘to reduce maintenance burden’ or ‘clean up the code base’ even when the code is modular and has no effect on other architectures. I think one of the most valuable resources moving forward is
@barracuda156 powerpc mac ports themselves, particularly the prebuilt packages. My point is simply that the community can count on people like you directly
@barracuda156 to provide support far more consistently than anybody upstream in the vast majority of cases. It is important for users who care about the platform and opensource support to continue to file tickets and bug reports but i wouldn’t hold my breath for a renewed interest in Mac PowerPC upstream. This is just my opinion of course and nobody is obligated to agree.
Thank you, we are on the same page here.
There are few things consider in regard to submission of patches upstream or to MacPorts (and in principle to other downstream distribution systems, just not many of them are there which can be considered).
1. What is often a no-go with upstreams (and may or may not be accepted to MacPorts, perhaps will be hard in any case) is something very complex and/or huge. For rather obvious and credible reason: it is hard to maintain such code for upstream (
in this case truly, and not only because they may not want to, but also because nobody of upstream team may even understand the code without consulting with very specific documentation, so it is likely to get broken pretty fast).
With exception of MacPorts earlier, I normally don’t bother trying to submit such patches. A typical example would be Qt-using ports: to restore compatibility with Qt4 takes a lot, even if most of fixes are trivial (restoring older code, adding conditions to use it). Also it is actually rather painful to write such patches in a way that can be mergeable in principle – and way easier and faster just to replace whatever needed, throwing away breaking code chunks, and have a fixed version for yourself. Another example are projects heavily using Apple ObjC/ObjC++ extensions and Cocoa: again, fixing that, if possible at all, often means maintaining two versions in parallel, and nobody wants that.
2. On a positive note, Darwin ppc issues are more often than not decomposable into a) powerpc issues and b) macOS SDK issues. It is easier to convince to accept a fix for either on their own than anything applying only to macOS on powerpc. Because all endianness and 32-bit issues apply to Linux and BSD, many of which are currently supported, unlike macOS (so the argument “oh that’s 20-year old OS, why bother” does not stand), and legacy macOS SDK issues are relevant for x86 systems, which at least are likely to have more users due to hardware availability.
There are perhaps very few scenarios where something is in fact specific only to Darwin ppc. Assembler is one (but assembler usage is usually limited nowadays, and then if a fix is tiny or separable – and easy to understand – it can be well accepted, even if it is specific to an old unsupported platform: my fix for coroutines was accepted to Ruby upstream, and Boost upstream accepted a joint work on fixing assembler in context library). Other case is some differences between x86 vs ppc for the same SDK: not many of those, but they exist.
3. MacPorts at least nominally supports 10.4+ and ppc/ppc64 archs. This does not mean, unfortunately, that something is systemically tested or fixed pro-actively, but as long as it can be shown that a bug affects one of supported systems and a fix is credible and understandable to a reviewer, it probably will be accepted. 10a190 is not a supported system, and while nothing in MacPorts T&C or conventions prohibits fixes specific to an unsupported system, there are folks who just don’t like it, and may be eager to spend time just to create trouble to you. Unfortunate reality, however: there were very few bugs genuinely specific to 10a190, and with 10.6.8 ppc now there are almost none such. It does not matter (well, it should not at least) on which system you demonstrate a bug, as long as it is understandable that it is relevant for 10.5 ppc, or for 10.6 regardless of the arch. Something which affects 10.6.8 ppc but also 10.6.8 Rosetta is in a grey zone; in principle, 10.6.8 Rosetta is an official Apple release and therefore should be supported; in practice, as I noted, some individuals just love to have it broken. Still, accepting a credible patch is up to a port maintainer and/or particular reviewer. So at least it could work. Just don’t bother submitting 10a190-specific patches to MacPorts. But also do not use 10a190 now yourself, use 10.6.8 ppc
