Let me have a different proposal.The issue I see is that Fedora has the policy of having single version of package in repository. So if there is package foo-1.0 and upstream releases foo-2.0, the foo-1.0 is replaced in repository with foo-2.0 despite there might be package bar-1.0 requiring foo-1.0
So how about allowing to have more versions of package in repository? In the example above, the foo-1.0 would be kept around as long as it is required by the bar-1.0. I believe that this would allow in quite some cases to track upstream closer.
Leaving aside the work which would need to be undertaken to make this work, there are some concerns:
* main concern could be what if there is identified security issue in foo-1.0?
* other issue is that having the bar-1.0 installed would prevent the update of package baz-1.0 to baz-2.0, which depends on foo-2.0.
both of the above have various solutions I leave to other to elaborate :) Vít Dne 24. 09. 26 v 1:52 Gordon Messmer napsal(a):
( 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.htmlPlease reply if you are interested!
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
