Dne 17. 10. 26 v 9:42 Gordon Messmer napsal(a):
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.0So 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.
This is not what I am proposing. Lets have more specific example: s/foo/openssl/. Fedora policies certainly allows to have openssl and compat openss3, but what I say is that if we left openssl-3.5.9 in the repository and added openssl-4.0.3, the DNF can resolve the dependencies in a way that the system stays in reasonable shape.
Granted, OpenSSL is likely bad example, because it is security sensitive package, but it would be fine for most other packages, such as e.g. rubygem-cucumber-cucumber-expressions, which I couldn't update, because rubygem-cucumber depended on older version (while having the same upstream!!!, luckily the cucumber release from last week seems to fix this).
In many cases they are parallel-available but not parallel-installable,
rubygem- packages are generally parallel installable and despite that, we don't keep old versions around. We rather break the dependency 🤷
Also please note that there even is no official policy/decision like "having single version of package". It was not always like that. It just happened over the years.
IOW, in theory, you could have e.g. one source package providing openssl-4.0.3 as well as openssl-3.5.9, but despite that, the openssl-3.5.9 would not appear in the repo. BTW having one source package providing multiple versions would be IMHO kind of elegant (although partial), solution to your problem.
Vít
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.
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
