Bug 251185 - graphics/mozjpeg conflicts with graphics/jpeg-turbo
Summary: graphics/mozjpeg conflicts with graphics/jpeg-turbo
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Sunpoet Po-Chuan Hsieh
Keywords: regression
Depends on:
Reported: 2020-11-16 14:16 UTC by Keren Sky
Modified: 2021-03-28 10:52 UTC (History)
6 users (show)

See Also:
bugzilla: maintainer-feedback? (sunpoet)


Note You need to log in before you can comment on or make changes to this bug.
Description Keren Sky 2020-11-16 14:16:33 UTC

This port fails to install when upgrading to the latest version. The error message indicates a conflict w/ graphics/jpeg-turbo. 

Is it no longer possible to have the conflict resolved like so: https://www.freshports.org/commit.php?category=graphics&port=mozjpeg&files=yes&message_id=201705131459.v4DExAq8088390@repo.freebsd.org

Best regards,
Comment 1 Keren Sky 2020-11-16 14:19:38 UTC
I forgot to copy and paste the exact terminal output:
===>  Installing for mozjpeg-4.0.0
===>  Checking if mozjpeg is already installed
===>   Registering installation for mozjpeg-4.0.0
Installing mozjpeg-4.0.0...
pkg-static: mozjpeg-4.0.0 conflicts with jpeg-turbo-2.0.5 (installs files into the same place).  Problematic file: /usr/local/bin/cjpeg
*** Error code 70
Comment 2 Dani 2020-11-16 14:45:54 UTC
Same problem here. graphics/jpeg-turbo is needed as dependency by multiple other pkgs, so there should be a solution to either excloude some stuff from mozjpeg or install in a different place.
Comment 3 Dani 2020-11-20 16:16:14 UTC
Comment 4 buganini 2020-11-24 14:51:52 UTC

With both mozjpeg-3.3.1 and jpeg-turbo installed, I have
246:-ljpeg.8 => /usr/local/lib/libjpeg.so.8
439:-ljpeg.8 => /usr/local/lib/mozjpeg/libjpeg.so.8
from `ldconfig -r`

USE_LDCONFIG is removed in 4.0.0

May we have some symbolic links like /usr/local/lib/libjpeg-mozjpeg.so.8 => /usr/local/lib/mozjpeg/libjpeg.so.8
to make it easier to create a py-pillow-mozjpeg slave port.
Comment 5 Sunpoet Po-Chuan Hsieh freebsd_committer 2020-11-24 20:00:31 UTC
Upstream changed to CMake which does not have --program-prefix.
But why do you need both ports at the same time?

(In reply to buganini from comment #4)
I'll add USE_LDCONFIG back. Thanks!
Comment 6 SolarCatcher 2020-12-17 11:37:21 UTC
As others pointed out already: quite a few other ports directly or indiectly depend on jpeg-turbo. I cannot upgrade mozjpeg to 4.0.0 because pkg then wants to uninstall quite a few other packages on my servers:
ghostscript9-agpl-base: 9.52_11
jpeg-turbo: 2.0.6
lcms2: 2.11_1
libgd: 2.3.0,1
libraw: 0.19.5
openjpeg: 2.3.1
php74-gd: 7.4.13_2
php74-pecl-imagick-im7: 3.4.4_2
phpMyAdmin5-php74: 5.0.4
tiff: 4.1.0
webp: 1.1.0

I would really need the old program-prefix back. If CMAKE does not offer this option, we should build a port mozjpeg3 keeping version 3 available, which seems to work for many of us.
Comment 7 Daniel Dowse 2021-03-28 06:49:57 UTC

i have made some patches they can be pulled from this github repo 


Please check and review if the patches can be used `as is` or not. 

Comment 8 SolarCatcher 2021-03-28 10:52:57 UTC
Great! Many thanks! I just built this Port on 13.0-RC2 and it does not conflict with jpeg-turbo. I was able to losslessly compress a test.jpg with

/usr/local/bin/mozjpeg-jpegtran -optimize -copy none -outfile test_optimized.jpg test.jpg

Could others confirm that these patches work for their use cases? Then we could ask the maintainer to accept the patches and have a new working mozjpeg which does not conflict with jpeg-turbo!