On Sat, Jun 17, 2023 at 9:12 PM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Petr Pisar wrote: > > 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. > > You can actually, if you set them to different ports. > > But the issue here is that you can have 2 completely unrelated packages > clashing over the version of some transitive dependency. Imagine not being > able to install a KDE application on GNOME or vice-versa because of the KDE > and GNOME stacks requiring a conflicting version of some "plumbing-layer" > library. That is exactly the kind of scenario I and others want to avoid. > > > 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. > > It is a different solution indeed, but I disagree about it solving a > different problem. It solves the *same* problem in a different, better (from > the end user's perspective – I know it is more work for the packager) way. I question the "more work for the packager" viewpoint. I'm not sure that's necessarily true, especially for casual packagers. From my perspective, any Fedora guidelines that I can pull directly from Fedora packaging documentation and merely have to modify a SPEC file, is *far* less work for me than understanding a whole separate MBS system and related tooling. Even if it's technically more "work" (time consuming or tedious), the work is much easier when it's building on existing knowledge. It's really about comprehensibility, and the degree to which you can capitalize on existing knowledge, that contributes to how much work is needed to use one solution vs. another. > > Kevin Kofler _______________________________________________ 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
