Fedora's modularity mess
Fedora's modularity mess
Posted Nov 30, 2019 21:02 UTC (Sat) by rahulsundaram (subscriber, #21946)In reply to: Fedora's modularity mess by amacater
Parent article: Fedora's modularity mess
Slackware doesn't have a dependency resolver and .deb as a packaging format isn't all that different from .rpm and doesn't solve the modularity problem. So I don't see how that would help at all. Feel free to explain
Posted Nov 30, 2019 21:41 UTC (Sat)
by amacater (subscriber, #790)
[Link] (5 responses)
The modularity and fast moving packages - there's a working alternatives system and the stable/testing/unstable ecosystem generally means that newer versions are being worked on at the same time as stable remaining stable. Comparable in size to Fedora but having longer term support.
Posted Nov 30, 2019 23:50 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
Posted Dec 2, 2019 9:50 UTC (Mon)
by kleptog (subscriber, #1183)
[Link] (3 responses)
So you don't have postgresql:10 and postgresql:11, you have postgresql-server-10:10.11 and postgresql-server-11:11.6 and the corresponding client packages. The libraries libssl1.1, libssl1.0.2 and libssl1.0.0 are also distinct packages, the package name reflects the ABI presented. Then the whole discussion becomes much easier, dependencies are clear and installing multiple versions of a single package becomes unnecessary (although it is supported if the architecture is different).
To refer to the article, since libgit2-21 and libgit2-27 are co-installable the entire issue vanishes. It doesn't matter if the version 21 disappears from upstream, it remains on the user's system as long as they need it.
To make this work smoothly is of course a large part of the rest of the policy regarding file placement and versioning but it seems to me to solve all the issues this article is discussing. There is the choice that this scheme does not apply to dev packages for building, I think mostly because of (for example) lack of useful tooling support for dealing with three versions of the ssl.h header file being installed at the same time.
Posted Dec 2, 2019 12:06 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Indeed. So switching from RPM to Deb solves none of the problems and packaging policy can be applied in an identical way in an RPM based system. In fact, such packages already exist in Fedora and is not fundamentally different from software collections (which was more heavily used in RHEL and did not see much adoption in Fedora). The modularity group is just trying a different approach to solve it
Posted Dec 2, 2019 17:01 UTC (Mon)
by amacater (subscriber, #790)
[Link] (1 responses)
Packaging policy can be applied equally to .debs and to RPM - but it isn't applied in the same way in most RPM based distributions and the IBM RPM ecosystem itself tends to depend on a mess of third party repositories, each from a small number of maintainers.
EPEL is packaged by Fedora maintainers using the libraries in Red Hat Enterprise as a base - so a third party repository for the main Enterprise distribution. Then you have Freshrpms / Livna / Elrepo / RPMFusion / whatever else Dag Wiers has contributed to :) (and whatever is today's hot repository).
Also you have the problem that the RPM ecosystem has historically only worked on a limited number of architectures so it's coming to ARM fifteen years late.
[And note, this suggestion from me is nothing new - I made a similar suggestion to rgb for the beginnings of the Beowulf project.]
Posted Dec 2, 2019 17:49 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link]
If we are talking about RHEL here specifically, there are essentially two repositories in widespread use
Core - Commercially supported by Red Hat.
Packaging policy has nothing at all to do with this split clearly. This is in impact of RHEL being a commercial product
RPM Fusion is akin to non-free in Debian. Others got merged into RPM Fusion years and years back. It is far more popular in the Fedora space than within RHEL community. There isn't anything new or "hot" here. Again, the difference here is a combination of Fedora licensing policy and Red Hat is a commercial entity and doesn't want to take on liability of distributing patent encumbered code. Nothing in the RPM format or packaging policy is going to change any of this. It also has nothing to do with the modularity effort. So I am afraid I don't see the relevance
Fedora's modularity mess
[Disclaimer: I've been using Debian since version 1.2 and Red Hat since 4.2 - I have to help support both but _still_ can't support developers wanting to use Red Hat for daily development with any degree of satisfaction.]
Fedora's modularity mess
Fedora's modularity mess
Fedora's modularity mess
Fedora's modularity mess
Fedora's modularity mess
EPEL - Community supported