Why does it matter?
There is no company with a little bit of sense or vision that will use any distro without first checking whether there is sufficient (paid) support for it and whether the necessary software they want to use can also run on it.
These kind of distros are nice niche products for a hobby club and a few avid autists who can do everything themselves and know it all better. In the end it is doomed simply because without commercial support a distro will never become more than fun for the hobby and small and small medium businesses. Every slightly larger company uses commercially supported distros because they simply can’t put the business in the hands of a hobbyist club.
Another build system means nothing at all, as long as the compiler and compiler settings are the same the only real difference is the way the code and artifacts are put in the right place and how the orchestration works around it. Think of the choice for CI/CD tool… A Jenkins pipeline or a Shipable pipeline really makes no difference, everything in shell or at least a python script makes no difference, the end result is 100% the same.
Of course one will be easier to work with than the other and you can have an endless discussion about which choice is the right one. I can tell you from experience that it really doesn’t matter and that the most important thing is that the system does what you need and is flexible enough to offer you the possibilities in the future (as far as you can estimate of course). make the builds the way you want.
I can make 100 identical builds with 10 different build systems in 10 different ways, which are 100% binary compatible. The only thing that matters is that the build system generates the correct output, for example. A slack message when a certain point is reached in the build, test results are sent to another system. The ability to have the build automatically place the artifacts in another repo if they meet certain criteria (successful tests, for example). I might like to be able to use the last successful build of that dependency if a dependency build fails (could be useful if you want to test the new SSH tools for example and don’t care at all about that potentially new version of netcat that is also in this build is expected)
There are endless reasons to switch build systems or to choose build system A over build system B. And all are very good reasons, but in the end the most important thing is the result and in this particular case that the result is 100% equal to the RetHat Enterprise Linux build. All the other bells and whistles don’t matter if you can’t promise that 100% compatibility, and that’s often much easier than it might sound if you switch build systems.
–