No subject

> I wondered why libjpeg-turbo would not incorporate libjpeg 9 features, and
> found this article explaining why:

The README shipped with the jpeg-turbo code has a similar explanation. Apparently the authors are very certain that no one will use the jpeg9 ABI even if that's just because of updating for updating's sake as happened here. Because even if you don't agree with the additional functionality provided, you can emulate the ABI with the new functions being stubs, or so I'd assume.

Maybe there's a lesson to be learned here: when much-used fundamental libraries change their ABI, follow the lead of what happens in Linux land Probably not what cutting-edge distributions like Arch or Gentoo do, but rather the ones with longer term support. 

As a side-note: thinking (100% wishfully, I'm aware) about this, and the productivity issues that can come with being too cutting-edge, I find it a pity that MacPorts (nor any of its brethren AFAIK) provides different updating schemes that would allow the user to select between always having the latest version of everything, and something that provides more long-term stability. But then I'm not even sure if Debian/Ubuntu really allow the user to configure such a choice (despite having an urgency indicator on each package version).

R.