Igor Raits wrote:
Why is it painful? You have all dependencies packaged that follow
semver (not like Go) and it is quite easy to build those packages.
Semver is just a convention on version numbers (and one that, IMHO, is still
open to human interpretation). It does not solve the problem at hand, which
is that even the compiler does not provide a stable ABI when it changes
version (affecting all libraries), let alone the libraries. (Semver only
says that incompatible API changes should lead to a bump in the front rather
than the back of the version number. That does not solve the problem that
incompatibilities happen to begin with. At least not as long as any upstream
can set any version number they wish at any time they wish.)
The lack of stable ABIs is what prevents building shared libraries in a way
useful to the distribution. Semver is not relevant there.
Another example here could be nodejs, even though it does not link
statically it is just PITA to package since ecosystem is just full of
very small libraries that do not really like to cooperate so you need
to have tens of different versions of a lib in a repo. I consider this
much bigger problem than the Rust has in Fedora.
IMHO, Rust and Go also have this exact same "[many] very small libraries"
problem. Maybe slightly fewer than Node.js, which really takes it to an
extreme, but still a lot more than C or C++.
The main issue is that it is too easy to depend on a library in all of
Node.js, Rust, and Go, because you just have to write one import line, and
the programming language's tooling will automagically pull the dependency
from the Internet. This is what leads to dependency explosion. It is also a
PITA for packaging, because Koji rightfully (for obvious security reasons)
prevents builds from accessing the Internet. In a language like C or C++,
the developer thinks twice before adding yet another dependency.
We also have Fedora CoreOS that uses
https://github.com/coreos/afterburn and
https://github.com/coreos/zincati that are written in Rust as well and
those are core system utilities.
The situation there is essentially the same as for rpm-ostree: Those are
core system utilities for CoreOS only, not for a default Fedora
installation.
This is yet another decision that makes Fedora CoreOS unattractive to me.
I don't think saying "Ditch Python, Ruby, Perl, … from the
system
components" is useful for anyone since you know that it is not going to
happen.
Actually, Ruby and Perl are already undesired in the core system layer,
because each language interpreter increases the size of all our live images.
There was an official effort to kick out Perl from the Workstation live
image years ago, which AFAIK has been fully implemented. And Ruby was never
used in the core system to begin with.
Python is a different story. There are people who are trying to get rid of
even that (see, e.g., microdnf), but in the default Fedora, it is probably
here to stay. I consider that unfortunate, because it is a heavy runtime
dependency, because it is more error-prone than fully compiled languages
(only syntax errors are caught at package build time, and even that only if
bytecode generation is set up correctly, whereas, e.g., type errors,
deprecation warnings, etc. are all spewed at the end user instead), because
it is not fully backwards compatible (even a new 3.n+1 release can have
small incompatibilities, and the transition from 2 to 3 was a huge
breakage), and because it does not perform as well as natively compiled
code. But I am not entitled to make this decision.
Kevin Kofler