On 2026-09-28 9:44 AM, Stephen J Smoogen wrote:
## Don't break rawhide
https://gordonmessmer.codeberg.page/dev-blog/2026/09/24/let-applications-select-dependencies.html
Due to the linear nature of time, a software release must exist before
other software can depend on it. A shared component must be released
before other software can be ported to its interfaces or tested against
it. In this way, change flows through code like light or sound through
their own mediums. This is the speed of compatibility.
Consequently, a shared component needed indirectly may not be compatible
with newer versions. An app that uses a component directly may need a
different release than one that uses it indirectly. An application that
uses a hypothetical "libEtc" might depend on features that were
introduced in 1.3, whereas another application of the exact same age
might not be compatible with release 1.3 if it uses "libEtc" indirectly,
as the dependency of a dependency, etc.
Those two applications can't coexist in a common prefix with a shared
version of libEtc.
So what do you do if you need both of those applications?
Today, if Fedora wants to ship both of those applications, someone has
to effectively fork *something*. Maybe they'll try to port the library
that isn't compatible with "libEtc 1.3" forward. Or maybe they'll try to
make the other application work with "libEtc 1.2". But either way,
Fedora ends up shipping something that its developers never tested and
don't want to support, and that hurts our relationship with upstream
developers. It also creates an enormous amount of debt. Debt means that
every release going forward may require a new port... or worse... when
the maintainers become to busy to handle ports, it may contribute to
dependency gridlock, which becomes the reason that maintainers stop
updating "libEtc" and the applications that use it in Rawhide regularly.
Right now, somewhere between 1/6 and 1/3 of Rawhide is significantly
behind upstream releases. I don't know how much of that is caused by
dependency gridlock, but my guess is that it's a lot. Fedora is losing
contributors, which means there are fewer people updating packages,
which means that updates become more difficult, which people find
discouraging, which means that more people stop contributing. Fedora's
integration practices also are a bill that comes due.
Another option is that *IF* "libEtc 1.2" is still maintained by its
upstream developers, so that its continued use is not a security risk,
then you can build the applications that need libEtc in containers, and
don't add the packages used for those containers to Rawhide or to
release branches. In this case, we can build the application that adopts
libEtc releases quickly without creating churn in Rawhide. (And
conversely, we may be able to relieve some of the pressure that is
currently causing Rawhide to lag behind upstream releases.)
I would like to build a project that demonstrates the second approach so
that Fedora can build things like vLLM without incurring the costs
associated with the former approach. A vLLM build in isolation is pretty
manageable. It took a little over a week for a single developer to set
up. Trying to build it in Rawhide would mean coordinating a team of
dozens of people, for every single release.
A comment I wrote in the discussion forum seems relevant here as well:
Integration work is valuable, and I’m glad Fedora contributors do it. I
don’t want to do anything that would stop them from doing it or
discourage them from doing it. But I think it has to be evaluated in
context. Just like there are exceptions to the stable release policy, I
think we should consider that some things don’t make sense to ship as
RPMs that target a Fedora release. When the cost of integration and
porting exceeds the value, there should be another option. And I think
the cost may exceed the value very frequently. I understand that we see
a lot of value in porting and integration work, but it’s important to
also understand that the /need/ for that work is imposed by Rawhide’s
structure. It looks important to us, but it looks important because we
created the conditions that require it to happen. Porting dependencies
forward is work that upstream developers /will/ do, they just aren’t
doing it on Rawhide’s arbitrary schedule. And so, while I’m sure that we
are proud of that work and many upstream projects appreciate the help,
we also need to consider that doing that work doesn’t make our work
easier. It perpetuates the problems that come from Rawhide's rolling
release model. No matter how much time we spend on porting and
integration work, six months later we’re going to have to do it again
for the next release. That might not be the best investment strategy.
Instead, we could develop the option to build some things in containers,
where they can update dependencies independent of Rawhide (and probably
often /ahead/ of Rawhide). And doing that might significantly reduce the
cost of maintaining Rawhide and improve Rawhide’s security posture. We
can still contribute to porting and integration work for things that we
care about. But doing it async makes it more like tending a garden and
less like fighting a fire.
--
_______________________________________________
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
