Add blog post about Ruby versions and Tebako version support

[ronaldtse]

What Tebako version do we support which Ruby version. Can we maintain multiple Ruby versions?

[maxirmx]

Tebako 0.5.4

• runs on Rubies 2.7.x, 3.0.x, 3.1.x, 3.2.x
• packages 2.7.7, 3.0.6, 3.1.4, 3.2.2

Let me write a detailed explanation

[maxirmx]

post-3.docx
post-3.pdf

This text attempts to answer recently discussed issues:

• Ruby versions and Tebako version support (Add blog post about Ruby versions and Tebako version support #19)
• Where Tebako compexity is (Add explanation to blog post about snap/flatpak/appimage #17)

@ronaldtse @CAMOBAP your feedback is appreciated

[ronaldtse]

I've moved the blog post into this PR:

• Add blog post about Ruby versions and Tebako version support #19

Please edit it there until it is ready to be published, then we can just merge it. Thanks!

[CAMOBAP]

your feedback is appreciated

@maxirmx thanks for the blog post

Few comments from my side:

• I propose to add links to components mentioned in the table, (tamatebako gem, CMakeLists.txt, tamatebako runtime gem)

• According to https://github.com/tamatebako/tebako/blob/main/CMakeLists.txt it looks like we use really "predictable"/small dependency list:

  • libncurses
  • openssl
  • libyaml
  • incbin
  • libdwarfs

  It looks like dey don't create a huge impact because of static linking, right?

[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"

[ronaldtse]

@maxirmx all of these details can be very interesting to readers. Can you please detail them in separate blog posts? Thanks!