Create a blogpost out of the comment about tebako patching

[maxirmx]

The full dependency lists on Ubuntu 20 is comprised of 271 package. Alpine needs more, MacOS requires less.
There is "dependency chain" tebako --> libdwarfs (out memfs access layer) --> dwarfs (memfs) --> facebook libraries (folly, fbthrift) --> google libraries (glog, gflags)
So, to see all dependencies tou need to consider:

• https://github.com/tamatebako/libdwarfs/blob/main/CMakeLists.txt
• https://github.com/tamatebako/dwarfs/blob/main/CMakeLists.txt

The fact that certain libraries to be built statically does not define the complexity. Complexity is mainly determined by the reason why static libraries cannot be installed from the standard package.

Few examples:

• brew formulae for glflags does not include static library. It is easy -- we just check if gflags.a is out there
• brew formulae for glog used bad options to build static library (I think the did not use PIC). It is easy -- we just build our copy of glog.a on MacOS if it is out there
• building static libarhieve is an art on any platform (https://github.com/mhx/dwarfs/pull/55/files), but of course it is doable
• alpine 3:16 did not support static jemalloc library (not sure about 3.18). It was doable but unconventional -- we have to patch system (libc) includes to get libjemalloc.a (https://github.com/tamatebako/tebako-tools/blob/master/ci-scripts/patch-system-includes.sh)
• libfolly is always static but starting from certain version folly heavily depends on weak references (== dynamic linking) to other libraries. Practically it means that newer versions of folly effectively block the possibility to link dependent libraries statically (I have better explanation somewhere in the comments). It is difficult -- we are using outdated version of folly but it becomes increasingly less compatible with newer versions of othe libraries. So thi one is a pain.

This is not the full list, there are several other items.

Intent of original text was to describe operational and not development complexity.
I was trying to say that

• we have tebako setup that builds a lot of libraries and it takes a lot of time. When we are done with setup tebako press is (relatively) fast.
• albeit tebako setup is complex all complexity is hidden. On supported platform you need three commands only: apt install or equivalent; "gem install tebako"; "tebako setup"

Originally posted by @maxirmx in #19 (comment)