Bug 199633
| Summary: | graphics/jpeg-turbo: includes should be installed, rework proposed | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Dmitry Marakasov <amdmi3> |
| Component: | Individual Port(s) | Assignee: | Dmitry Marakasov <amdmi3> |
| Status: | Closed Works As Intended | ||
| Severity: | Affects Many People | CC: | adamw, bapt, bdrewery, bytestore, jbeich, miwi |
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(bytestore) |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
The concern that I have about this approach is that libjpeg-turbo is designed to be an actual, full, drop-in replacement for libjpeg, as well as providing other stuff. Patching a few ports to look for it under a new name makes it no longer a drop-in replacement for libjpeg. Well, there's currently no way to implement a drop-in replacement on the ports level, since the ports conflict, and utilities can't replace jpeg with jpeg-turbo if it's needed. In it's current state, libjpeg-turbo is not a replacement for jpeg at all as it doesn't install includes. On the user level, the ability of replacement remains with a separate port which installs libmap file. I'm not entirely clear on the implications of provides/requires in the new pkg. If that will allow libjpeg-turbo to behave like a proper drop-in replacement, then adding the missing header files to the libjpeg-turbo port seems like a reasonable option. If the libjpeg-turbo port can't be modified to let it act as a proper drop-in replacement, them I'm 100% with you on the changes you proposed. (In reply to Adam Weinberger from comment #3) > I'm not entirely clear on the implications of provides/requires in the new pkg. > If that will allow libjpeg-turbo to behave like a proper drop-in replacement, then adding the missing header files to the libjpeg-turbo port seems like a reasonable option. That's something related to what we needed, but afaik it is still far from being usable for the purpose. pkg people, any comments? Summarizing, jpeg and jpeg-turbo install the same set of includes/libs. Another port requires jpeg-turbo specifically, but most other ports depend on jpeg. Any way to solve this without using filename suffixes? > If the libjpeg-turbo port can't be modified to let it act as a proper drop-in replacement, them I'm 100% with you on the changes you proposed. Just make a common port to install the development files and have everything depend on it. Remove the development files from the other ports. ports r390308 slightly improved the situation. Once libjpeg-compatible headers/libs are installed again use can define JPEG_PORT=graphics/jpeg-turbo in make.conf to build a package repo against libjpeg-turbo API optimizations. (In reply to Bryan Drewery from comment #5) > Just make a common port to install the development files and have > everything depend on it. What if my port wants to use -turbo optimization for libjpeg API? Neither IJG libjpeg nor libturbojpeg provide it. And the app isn't smart to fall back to non-optimized routines at runtime. See www/firefox/files/patch-ijg-libjpeg for an example. Ideally, the hack should go away in future. Hi, Any progress here? Though the port may be simplified, since switch to jpeg-turbo it's not really relevant. |
I have a new port which explicitly requires libjpeg-turbo, including its headers (it uses stuff not present in headers of graphics/jpeg). Currently the headers are not installed. The primary purpose of this PR is to add headers installation - this may be done by simply moving them into dedicated directory (e.g. include/jpeg-turbo). However I also propose ravamp of jpeg-turbo ports as the way they are split is seemingly meaningless, confusing and hard to use. I propose to merge these into a single port which installs all parts of jpeg-turbo in a way to not conflict with graphics/jpeg: - lib/libturbojpeg.{a,so,so.*} - include/turbojpeg.h - lib/libjpeg-turbo.{a,so,so.*} - include/{jconfig,jerror,jmorecfg,jpeglib}-turbo.h - binaries and manpages This way - jpeg-turbo's own interface (libturbojpeg, turbojpeg.h) may be used as-is - jpeg-compatible interface may be used by patching consumers - separate port which just installs libmap.d entry may be added to use by ones who want to transparently use libjpeg-turbo library instead of one from graphics/jpeg. Note that I deliberately use filename suffixes for graphics/jpeg conflicting library and headers. We could use dedicated subdirectories and leave filenames unmodified (e.g. include/jpeg-turbo/{jconfig,jerror,jmorecfg,jpeglib}.h, lib/jpeg-turbo/libjpeg.{a,so,so.*}), however it's hard to handle as include/link paths come from many places and consumers may end up using graphics/jpeg stuff while they've wanted turbo.