-
-
Notifications
You must be signed in to change notification settings - Fork 7.3k
Build libvips from source in Dockerfile #30571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Testing this now. Update: So far so good. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good, having a more up-to-date version with fewer modules we don't use is certainly appealing.
However, there are two things I'm a little wary about:
- this adds some overhead in updating libvips, e.g. to keep up with security patches
- this will likely increase image build time, especially on ARM
The libvips compile usually adds about 12 seconds to the image build time in my testing. ARM uses the native builder in the GitHub workflow now so it shouldn't be any different? I just looked at the test build in GitHub actions and it showed the process took 48 seconds there. |
We should be able to have Renovate open PRs for libvips bumps using a custom config: https://docs.renovatebot.com/modules/manager/regex/ |
TBH This kind of housekeeping is generally handled by the non-ruby technical people like myself. |
When paired with #30602 the libvips version will be monitored by Renovate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! @ClearlyClaire do you want to have a look as well?
Extraction of libvips only components from from #30569
This preserves all of the benefits of compiling libvips individually (Controlled version adoption & Optimized library selection) however Docker image size remains at around 1GB due to inclusion of X11 as required by ffmpeg still being loaded by Debian repos.
libvips42
, ImageMagick core is also installed as a fallback for some image formats, when the ultimate goal of Add support for libvips in addition to ImageMagick #30090 is to ultimately remove IM from the codebase entirely for all the reasons why Vips is superior.Vips compile/library settings
[--build-arg VIPS_VERSION="8.15.2"]
libjpeg-turbo
is used for JPEG processing which is 2-6x faster than standardlibjpeg
. Another option would be to usemozjpeg
but this library is not available in Debian and would required another direct compilation.cgif
is used for GIF processing, which if not present would require Vips to fallback to ImageMagick.libspng
is used for PNG processing, which is similarly more performant than the standardlibpng
package.libwebp
is used for WebP processing.libheif
is used for processing HEIC/HEIF images.orc-0.4
is used for some SIMD operations instead ofhighway
due to the Debian repos not containing a version that is suitable forlibvips
but this could either be compiled directly or evaluated later if Debian packages are updated.libimagequant
is used for libvips to write 8-bit PNG and GIF files, with an alternative beingquantizr
that is not available in Debian repos but could be built directly.