( I have also posted this topic here:
https://discussion.fedoraproject.org/t/would-your-package-be-easier-to-build-if-you-could-select-specific-releases-of-dependencies/202746
)
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:
https://gordonmessmer.codeberg.page/dev-blog/2026/09/11/i-packaged-vllm.html
Please reply if you are interested!
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
