#59913 closed defect (fixed)
FreeRDP @2.0.0-rc4: Error: Can't install libjpeg-turbo because conflicting ports are active: jpeg
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | RJVB (René Bertin) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.2 |
Keywords: | Cc: | dbevans (David B. Evans), cjones051073 (Chris Jones) | |
Port: | FreeRDP |
Description
FreeRDP cannot be installed on the buildbot workers (so we cannot distribute a binary, even if the port is distributable) because:
Error: Can't install libjpeg-turbo because conflicting ports are active: jpeg
This was caused by [900fde8631792e3819933a0a249173bcc2b79506/macports-ports].
It was fixed by [31562966e7c452a5323b143bfd2b9b8817210598/macports-ports].
The fix was reverted in [7f1fe8f84df5b9bd76f5d3ed486fcfe7264fb685/macports-ports]. Why?
We don't have a good way of accommodating libjpeg-turbo in MacPorts right now. Offering libjpeg-turbo as an alleged drop-in replacement for jpeg, as we are currently doing, is simply broken. See #38907.
Change History (4)
comment:1 follow-up: 3 Changed 5 years ago by RJVB (René Bertin)
comment:2 Changed 5 years ago by Chris Jones <jonesc@…>
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:3 Changed 5 years ago by jmroot (Joshua Root)
Replying to RJVB:
Only because someone has been deaf for 5 years now to the argument that the jpeg V9 API is purely academic, not used IRL and that just about everyone else uses libjpeg-turbo.
Let's not present speculation as fact. There are multiple reasons why changes may not be made, and not agreeing that the change should be made is only one of them. Nobody in favour of the change has ever contributed a patch in those 5 years.
comment:4 Changed 4 years ago by Chris Jones <jonesc@…>
In 417e9b0e2feb2ee0765bc1cbe2861bf8b45825e1/macports-ports (dar, master, py38-reproject, revert-6945-rust-1.43.0, wireshark):
I only noticed that this particular change had been reverted when my initial PR was committed. I didn't look to understand but re-reverted in my subsequent PR that addressed another issue, openly enough that it should have been picked up by the review. I'm sorry for that (but can't really apologise for it... :) )
Only because someone has been deaf for 5 years now to the argument that the jpeg V9 API is purely academic, not used IRL and that just about everyone else uses libjpeg-turbo. See my comment in #38907. In short: port:jpeg can provide a variant that causes it to be installed in a subprefix (with just the v9 runtime library exposed in $prefix/lib to satisfy link requirements of installed ports); a small patch
sharedlib/CMakeLists.txt
from port:libjpeg-turbo so it uses compatible library versioning numbers will then make it possible to switch back and forth between the 2 ports at will. No changes to actual code are required.Please feel free to fix the depspec again. I'd do it myself if I had commit access; I won't have time for PR business for a day or two.