Objective Review: We integrate programming language stack ecosystems

Project Discussion
, ,
1

We’re working on Fedora Strategy 2028 — our next five-year plan. We are now reviewing those Objectives and their associated Impact. Read this guide for details on the current planning phase.

This Objective is part of the Theme “Fedora leads in Linux distribution development” and the Focus Area Technology Innovation & Leadership. For general discussion of this focus area, please see the topic Fedora Strategy 2028: Focus area review (Technology Innovation & Leadership).

Objective and Impact

Objective: We integrate programming language stack ecosystems.
Impact: Developers choose Fedora Linux because we provide a straightforward programming environment that works the way they expect.

At the dawn of Linux, there was really no such thing as package management. Then, distros built tools like RPM — consistent ways to describe how to build software, attach important metadata, and distribute pre-compiled binaries. This worked very well, and is the method by which we include all software in Fedora Linux.

But, meanwhile, every programming language — Java, Python, Perl, NodeJS, Rust, Go, etc., etc., has developed their own “native” packaging format. Developers tend to avoid rpm (or dpkg, or whatever else), possibly begrudgingly producing something in distro format as a last-step output. And not without reason — modern languages tend to have nicely integrated package management with a lot of convenient features (and less of the accumulated complication of decades-old RPM specfile syntax).

We currently go to great lengths to re-package libraries and modules from these language package formats into RPMs — doing so in some way is currently a prerequisite for getting an application using those dependencies into the Fedora package collection. This process does provide significant value, but it also causes a lot of friction, both in Fedora and for people coming to Fedora.[1]

I have some ideas, but I don’t know what the right answer is here — and the Council does not want to dictate one. Maybe we find a better way to automate language-specific-to-RPM conversion. Maybe we teach DNF how to work with those language-specific packages directly (and host our own repositories in those formats?). Maybe something else entirely! But: no one else has solved this. If we do this well, it will be easier to provide more software in Fedora Linux directly[2], and it will be easier for developers to come to Fedora and work comfortably as they are used to.

Our goal now

For this Objective and related Impact, validate that:

  1. If the Impact is achieved, it’s reasonable to expect an increase in active Fedora contributors.
  2. Success in the Objective logically results in the intended Impact.
  3. That link is reasonably sufficient — that is, it represents everything needed to have the Impact.
  4. While there might be other ways to have similar Impact, the chosen Objective is the right one for Fedora right now.
  5. The wording is precise and clear. The Objective is concrete, and the Impact is (at least a little bit) inspirational. Together, they fit into this Focus Area.

Bonus. If you can improve the longer explanatory paragraphs at the top of this post, that’s helpful too!

As outlined in the roadmap, this post will close in one month.

  1. See this devel list message and replies — there is a lot to talk about here! ↩︎

  2. which ties into the container and flatpak Objective ↩︎

2

I have to mention that most of the language ecosystem can be easily automated. We already have done that for Rubygems @rubygems/rubygems Copr and PyPI @copr/PyPI Copr These repositories contains hundred thousands of packages and are automatically rebuild when new release is available - that produce few thousands new build every day. This can be extended to other ecosystem if requested/needed.

1 Like
3

How much do modern users still want us to provide a programming language stack where the core might lack behind upstream up to six months in the worse case (e.g. when a new version of perl, python, ruby, java, … barely misses a new Fedora release due to bad timing)?

From my quite limited view into the world of programming I get more and more the impression most people primarily want either the “latest and greatest upstream version” or something that doesn’t change frequently (aka “stable” / LTS). Some delay for the sake of stability seems to be fine for people, but not up to six months.

That among the reasons why I proposed a different release model recently with releases every four weeks and two distro streams similar to Firefox and Firefox ESR: knurd: How would you change Fedora, if you became its supreme leader

4

I would strongly recommend focusing on the user experience here, rather than integrating things. As you note, it’s very common for developers to want to use what’s provided by the language ecosystem instead of what’s provided by the OS.

It would be nice to have out-of-the-box, containerised developer environments for users to leverage (with their choice of editor, of course). A nice thing about this approach is that you wouldn’t necessarily need Fedora (on the host) to leverage them. An example of this is my flutter-toolbx image for toolbx, which I used when I was working on a Flutter project.

Is the right answer to build Fedora User Groups that then develop documentation, provide steering, etc on how to develop on using Fedora?

5

This topic was automatically closed after 31 days. New replies are no longer allowed.