Pros:
+ control version of all dependencies (It won't happen that updating some dependency will break build, we can use latest version of all dependency)
+ we can stop thinking about supporting old versions of dependencies
+++ user-friendly (anyone can download our single .deb and immediately write a microservice without worrying about missing any dependencies)
+ we will be able to get the same stacktraces absolutely everywhere
+ we can compile with any с++ standard
Cons:
- if CVE is found in any dependency, we must manually update version with fixes this dependency, recompile and re-upload .deb- the first time it will take time
->-depends onglibc++->glibc->kervel versionglibc2.39: minimumkernel version 3.2Upgrade gcc:
https://github.com/docker-library/gcc/blob/master/14/DockerfileBefore: OS:
Ubuntu14.04Kernel version:4.4Compiler:gcc4.8.2glibc:2.23(libc.so) glibc++:2.23 +-(libc++.so) c++ standard:< 11After manual upgrade: OS:
Ubuntu14.04Kernel version:4.4Compiler:gcc14.0.0glibc:2.39(libc.so) glibc++:2.39 +-(libc++.so) c++ standard:< 29 +-(accept c++23)We must remove all
find_packageand add dependencies assubmoduleorCPMand compilecurlprotobufgrpc...We can compile all with
c++23 standardLink all static (includeglibc)Profit!
We can ship userver work with minimum
kernel version 4.4userver-all-linux-amd64.debuserver-all-linux-arm64.deb~userver-all-macos-amd64.deb~ ~userver-all-macos-arm64.deb~Pros:
+control version of all dependencies (It won't happen that updating some dependency will break build, we can use latest version of all dependency)+we can stop thinking about supporting old versions of dependencies+++user-friendly (anyone can download our single.deband immediately write amicroservicewithout worrying about missing any dependencies)+we will be able to get the samestacktracesabsolutely everywhere+we can compile with anyс++ standardCons:
-ifCVEis found in any dependency, we must manually update version with fixes this dependency, recompile and re-upload.deb-the first time it will take time