On 2026-10-14 11:31 AM, Vít Ondruch via devel wrote:
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?
Fedora policies allow us to have as many versions of a package as
needed, provided they are follow appropriate conventions for compat
package naming. In many cases they are parallel-available but not
parallel-installable, which is one of several problems that can be
solved by publishing software in container images like Flatpak rather
than composing them in package-mode systems.
The bigger problem is that an application's dependency set is not flat.
You may have an application that uses openssl-libs directly, but also
indirectly through grpc. In that case, it's not enough to have multiple
versions of the openssl-libs package, you'd also need variants of grpc
linked to each possible openssl-libs. And if you try to do that, your
package set explodes in size with all of the possible combinations.
I think that can only reasonably be solved using a build-time dep solver.
So, I am proposing that by providing dist-git branches that track
upstream releases, a build-time dep solver could build the required
openssl, and the required gprc, and then the application, and then using
a private repo containing the packages generated by that build sequence,
build a container image that users could consume.
That process decouples the application from the distribution. The
application no longer needs to rebase its dependencies when the OS does,
and for many applications that will mean they can update sooner. It also
means that the OS may be able to update its dependencies faster by
decoupling applications that update later than the set in the OS.
* main concern could be what if there is identified security issue in
foo-1.0?
While most projects aren't LTS, most of the security sensitive
components are stable releases. They continue to maintain release 1.0
for a while after the 2.0 release series begins.
I don't think it's a good idea to publish applications that rely on
unmaintained libraries, but I think we should allow them to use
"foo-1.x" for as long as those releases are maintained, upstream.
--
_______________________________________________
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
