#47808: port:jpeg proposal to prepare for making port:libjpeg-turbo the default jpeg dependency --------------------------+-------------------------- Reporter: rjvbertin@… | Owner: ryandesign@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: jpeg | --------------------------+-------------------------- Comment (by rjvbertin@…): Replying to [comment:3 ryandesign@…]:
I don't really understand the benefit of doing it this way. I propose to do it the way I [https://lists.macosforge.org/pipermail/macports- users/2015-May/038587.html described on the mailing list]:
I have been participating in that thread... The way proposed by this patch is in no way incompatible with the way you propose, IMHO it complements it, and makes it less of a "one-shot that shouldn't be missed" venture.
verifying that libjpeg-turbo works ('''''or at least builds''''') correctly
Is having an escape route ready if it only builds such an unimaginable idea, or even the idea of keeping the original/traditional/reference port around such that it can be co-installed with whatever it's going to be replaced with? My professional as well as personal experience (as if they could be separated...) tells me that users (myself included) who rely on a central library like this rarely appreciate it if it's replaced behind their backs without as much as an option to opt-out and keep using what they've always been using. I'm quite certain that I've seen a statement in the libjpeg-turbo documentation (README or elsewhere) that there is no guarantee that the software renders to a result identical to what libjpeg would have given, despite the ABI compatibility. For me that is sufficient reason to keep the port around. [small]Sometimes I wonder what MacPorts is supposed to be - a show-case what FOSS can be installed through it and that's catering to people who'd use Arch or Gentoo and spend their computer time keeping the system up to date, or something that's aiming to support productivity that's not MacPorts-related.[/small] -- Ticket URL: <https://trac.macports.org/ticket/47808#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X