V Thu, Jun 15, 2023 at 01:33:38AM +0200, Kevin Kofler via devel napsal(a): > Petr Pisar wrote: > > I spent some time thinking how to approximate the nice features with > > current state of RPM, Koji, and DNF and come up with this approach > > <https://ppisar.fedorapeople.org/postmodular/>. The linked approach > > achieves it at the expense of dedicated build targets and an inability to > > introduce completely new modules (as opposite to new streams of existing > > modules) after releasing an installation media. > > So the linked approach emulates Modularity with its main issues (in > particular, the risk of dependency version conflicts ("RPM hell") between > packages, due to the mutual exclusiveness of the different versions of a > "stack") by massive abuse of the Conflicts RPM tag (which is frowned upon > for exactly the aforementioned reason) and without an opt-out (because you > want to drop these packages into the main repository rather than the > optional modular one that is now going to be disabled by default for a good > reason). I fail to see the improvement from that proposal. > You got it right. It is to emulate Modularity features without Modularity. > If you want to build packages with this (selectable mutually exclusive > versions) approach, please keep using the normal Modularity I prefer using the normal Modularity. However, there is a strong pressure to remove it from Fedora. See <https://fedoraproject.org/wiki/Changes/No_default_fedora-repos-modular> and <https://fedoraproject.org/wiki/Changes/RetireModularity>. > and accept that > users now have to explicitly opt in to those modules. That's exactly what killed the current modularity. Nobody felt a presure to fix the tooling because Modularity was off by default. > And in particular, please accept that non-modular packages are not allowed > to require one of those modules (or in particular, a specific version > thereof). Attempting to work around those requirements (designed to protect > users from version conflicts they cannot resolve) is a very bad idea. > I understand the horror that you can have two packages which cannot be installed at the same time. The same as you cannot start httpd and nginx services at the same time. But now the conflict is visible on RPM level. I think it's a matter of the policy. Not of the underlying technology. Technically you could build and push into repositories a nonmodular package which depended on modular packeges even in the old Modularity. It were only people who did not do it and policies which were set against it. > If you really need a package to depend on a specific version of a library, > that library version should be packaged as a parallel-installable > compatibility library as per the packaging guidelines. > Of course. My proposal does not forbids it. If users of the parallel-installable packages are fine with rewriting all their RPM dependcies and file locations in their applications, then parallel-installable packages are a perfect solution. It's simply a different problem with a different solution. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
