I’ve used Red Hat / Fedora systems for almost 30 years. As an SRE, one of the things that has been most valuable to me has been not just the distribution, but RPM as a build tool. The spec files offered reusable, composable build workflows designed by people with experience integrating components into a coherent system.
Earlier this year, I proposed an initiative that was mostly aimed at improving our build processes. Fedora’s systems are great for building Fedora, but it’s sometimes difficult to extend them to build applications *for* Fedora. In particular, large, complex applications tend to be compatible with specific releases of their dependencies, and as their dependency tree grows deeper, it also becomes less likely that it can coexist inside the distribution with similarly complex applications.
I recently completed a prototype of a couple of tools that I used to package vLLM, because it exhibits those characteristics. The tools themselves are very similar to tools we have in place now. The configuration for an application build is very similar to the configuration we use for a Flatpak build. The main difference is that adding branches to a component’s dist-git repo which mirror upstream release branches allows a developer to select the release series of each component, independent of the version that appears in a Fedora release.
That doesn’t necessarily work well in a mutable package-mode system, but I think it works very well for isolated builds, such as container images (including Flatpak).
I’d like to discuss adding “upstream-release branches” in Fedora dist-git. Although it’s a small change, I expect we’ll need to discuss various aspects in detail, in a series of threads. Among other topics, we will probably discuss whether those branches can be automated to avoid increasing maintainer workload (I think we might have the confidence to do that since they wouldn’t be used directly by distribution releases). We’ll need to review previous branch-management implementations to see if any previous work is reusable or needed. We’ll need to discuss whether there are concerns specific to Forgejo. We’ll probably discuss whether we can use quay.io and the existing Flatpak registry or if a separate registry is needed.
But before we discuss any of those topics, I’d like to hear first from people who think that this would help them. Would having branches that track upstream releases, so that they can build an application and dependencies decoupled from the distribution release, targeting a container output make it easier to build a package that you maintain? Would it make it possible to build something that you would like to build but currently cannot? Would these tools be useful to you outside of Fedora, to build software for your own?
My experience building vLLM is described here.
Please reply if you are interested!
(which makes it possible to bring dependency-hell-affected software to Fedora). However, this is a security disaster, given that we are responsible for fixing CVEs and should aim to have each library in the system only once.
to have a policy that promotes and maintains multiple versions in parallel as the default model, because it results in infinite combinations that have to be managed somehow. This breaks any reasonable community or commercial maintenance model since behavioral and security flaws can’t be fixed at any level of the stack reliably. Fedora Modularity also proved that doing this was just technically hard. If this model propagated to RHEL at scale, I don’t think Red Hat would consider RHEL a successful product anymore as the costs would massively eat away at the profit margin and destroy the value proposition of the product.