Re: Modules without modularity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux