On 9/24/26 22:14, Gordon Messmer wrote:
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.
Where is the vLLM spec, infrastructure used to build it into rpm,
containers or whatever? The only link I could find is your blog post,
but that did not clarify these things.
But more importantly, what is each packager's maintenance look like in
this approach. Just at a glance I find it incredibly more complicated
having to make sure each release is compatible with each toolchain in
each Fedora version, or even worse having a combinatorial explosion
patches. The current workflow assumes that everything will work, that
upstream has made it work for everything, but what happens when it does
not. If this can run for a while on your side and you can show what the
typical maintenance looks like, having experienced how things can break
and recover there, then maybe this would converge to something that is
easier to understand and judge (currently the proposal is painted as
having only benefits and if we have to come up with failure modes to
compensate, the discussions are very skewed).
And to emphasize a point made in a different part of the thread, what
value does Fedora bring in this model? Why not use Nix for all of this?
Why not use a container base that upstream prefers or distributes?
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?
Why not both. Upstream is dealing with different issues than downstream.
For example a FTBFS issue in the python build-system.requires would
likely not be caught in the upstream CI, and even more, would they even
care to contribute down their dependency chain to fix that? Do some
upstreams even have proper CI to track dependency updates? On the other
hand, in downstream the major issue is making things compatible with
everything
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.
That is a communication issue, and should we not try to fix that instead
of throwing everything out for a different model? If someone does not
try to upstream first, isn't that something that should be addressed
instead?
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.
Why don't you start with your dependency chain?
--
_______________________________________________
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
