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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
