<div dir="ltr">On Mon, Feb 9, 2015 at 7:13 PM, Ryan Schmidt <span dir="ltr"><<a href="mailto:cairo-2015@ryandesign.com" target="_blank">cairo-2015@ryandesign.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br>
On Feb 9, 2015, at 8:26 AM, Andrea Canciani wrote:<br>
<br>
> What is the policy for supporting old MacOS X versions in MacPorts?<br>
> The homepage seems to state that the main targets are the latest 3 versions, but it looks like over time the support for older versions was preserved (at least based on the news here: <a href="https://trac.macports.org/news/" target="_blank">https://trac.macports.org/news/</a> ).<br>
<br>
</span>"Support" is different from "works" or "doesn't work". We "support" the last few versions of OS X, meaning if something in MacPorts doesn't work on those systems, we intend to fix it. MacPorts itself "works" on 10.4 and later; there is no reason to artificially break MacPorts on older systems that it still works fine on. MacPorts "doesn't work" on 10.3 and earlier (it doesn't compile, and hasn't for many years). Whether any individual port works on any particular system is another matter entirely. Many ports still work on 10.4, just as many others do not. Over time, as software is updated and developers stop testing on older systems, the number of ports failing to compile or run on older systems inevitably increases. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> Would it be possible to keep cairo 1.14 on 10.4 and to only upgrade on other MacPorts targets?<br>
<br>
</span>Possibly. MacPorts was never designed to have a port whose version number can change based on OS version or other criteria, but it has been done once or twice before. As long as newer versions of cairo don't fix bugs or introduce new features that other software relies on, this could work. It would add a lot of code to the cairo Portfile -- more code, I'm guessing, than if the problem were just fixed correctly.<br></blockquote><div><br></div><div>The problem we are facing is that Apple's libraries are incompatible between 10.4 and recent versions of the operating system: the 10.4 version does not provide CoreText, while in 10.10 they deprecated the old font API (and in iOS 8 they apparently removed it).<br></div><div>It is not completely clear what to have this problem "fixed correctly".<br>We can introduce a compatibility layer in cairo, so that it can attach to whatever underlying API is available (my suggestion above). This would obviously increase the complexity of cairo and it would make it harder to test.<br>Alternatively we can fix the problem for 10.10 in the most straightforward way. This prevents cairo from working on some old systems (10.4), but I assume that it might be an acceptable compromise (if you want to run the very latest version of libraries/programs, you might also have to update the operating system).<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> What is the usual approach in MacPorts for software that depends on modern systems (example: latest LLVM versions)?<br>
<br>
</span>The usual approach for ports that cannot be installed on a user's system is for them to print a message explaining why. In the case of llvm, we maintain multiple ports, one for each major version of llvm, so that users on older systems can still install the latest version that works for them.<br></blockquote><div><br></div><div>This approach looks very convenient! Would forking cairo-1.14 and cairo-latest involve complex changes to the Portfile?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> I can write a patch that implements the dynamic discovery of the available API, which should restore support for 10.4, but I expect cairo to eventually drop support for 10.4 (currently Cairo has no explicit support timelines, but I think that keeping in sync with Firefox requirements would make sense).<br>
<br>
</span>Well Firefox already requires 10.6 or later. 10.4 support was dropped years ago, leading to the creation of TenFourFox to fill the gap. I don't see a reason to arbitrarily drop support for older systems, but if you choose to require 10.6 or later, that means you'll be dropping support for all Macs having PowerPC processors; 10.6 and later require an Intel processor.<br></blockquote><div><br></div><div>Sorry, I did not mean to express the intention to artificially break cairo on 10.5.<br>I would not actively prevent cairo from working on old versions, but I think it might now be reasonable to accept changes that improve cairo or fix issues on recent versions even if they break the old ones.<br></div><div>In particular, the commit being discussed above breaks 10.4, but it seems to be required in order to let cairo-quartz work on MacOSX 10.10 and iOS 8.<br><br></div><div>Andrea<br></div></div></div></div>