On 2026-09-24 2:52 AM, Cristian Le via devel wrote:
We have mechanisms to package multiple versions of dependencies as the language/ecosystem allows it, and in other cases we have vendoring.
As far as I know, we don't generally allow vendoring of Python libraries, and even if we did, vLLM's stack is full of Python modules that require compilation, so "vendoring" would mean duplicating the build phase of many dozens of modules directly in the vLLM spec.
The prototype demonstrates that a better system is possible.
I see on a regular basis our packagers contributing to upstream making things compatible with the latest versions, flagging important vulnerability updates, and just coming up with better improvements in the tooling ecosystem.
Sure. And sometimes that works. But is Fedora the place to do that work? Or should it happen in the upstream project?
I think that it's *really* important to also remember that this very often does not work out. Packagers adapt one component to try to make it fit with whatever happens to be in the distribution, and it's good enough that the build succeeds and tests run, but then the application doesn't work well for users and they file bugs with the upstream project. Now the upstream project is getting bug reports from users that are the result of a build that they never tested and never intended to support.
Applying patches that don't exist upstream is inherently adversarial. It contributes tension and resentment between Free Software developers and the distributions that modify the software they release. I believe very strongly in the "upstream first" principle.
Sometimes it works, but there are costs to the user experience and to the project's reputation when it doesn't.
Today, it's often structurally required. We don't have good options otherwise. There's no realistic way that I can build vLLM in Fedora without patching an unknown number of projects to make them compatible.
I think we should have a process that doesn't require patching, for applications where things don't align.
It's perfectly normal for things to not align: https://gordonmessmer.codeberg.page/dev-blog/2026/09/24/let-applications-select-dependencies.html
I can understand that some packagers veiwpoint of just wanting to get something out the door and have the package done and ready to use. But what about the maintenance? I would appreciate if proposals such as these come with receipts of the experience in the maintenance
Yeah, that's why I packaged vLLM rather than proposing the practice, in the abstract. The vLLM build *is* receipts.
In any case, I expect to discuss the costs and benefits at length in a future thread. For now, I'm hoping that people will identify package they have to patch to build, or packages they can't build at all in the current structure.
-- _______________________________________________ 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
