Re: [Modularity] Module streams with two different, non-overlapping, package sets?

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

 





On Thu, Jun 21, 2018 at 11:56 AM Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> wrote:
On 06/20/2018 04:15 PM, Stephen Gallagher wrote:
> On Wed, Jun 20, 2018 at 10:06 AM Mikolaj Izdebski <mizdebsk@xxxxxxxxxx>
> wrote:
>
>> On 06/20/2018 02:30 PM, Petr Šabata wrote:
>>> Parallel installation of streams on a single system indeed
>>> isn't supported at this point and isn't planned anytime in the
>>> near future.  In general it's a more complicated problem than
>>> it might seem at first.
>>
>> Could you elaborate and explain what's so complicated about it?
>>
>
> The short answer is that there exists no generic solution for
> parallel-installation. Many packages rely on well-known resources[1] and
> cannot be parallel-installed at all. Other packages *may* support
> parallel-installation but consumers must take special steps to enable
> support for it.

In general case, when packages conflict, I would agree. But as subject
says, this is about a special case - non-overlapping, non-conflicting
package sets, which can be installed in parallel without taking any
special steps, like java-1.8.0-openjdk and java-11-openjdk that were
brought up in the first message.


Yes, but in order to support that in Modularity, we would need a general-case solution that would work for all packages. Just because *some* RPMs don't conflict between versions doesn't mean that a generic solution can be built for all RPMs.
 
> I don't have a good link right now, but folks at Red Hat did a number of
> customer studies and determined that in real-world deployments,
> parallel-installation was very rarely used. Generally, the OS was
> established with a standard set of packages and then anything that needed
> an alternate version was deployed as a VM or container.

Some packages are designed to be parallel-installable for a reason -
because users expect and require that. OpenJDK is an example of such
package. Even different version-releases of the same component can be,
by design, installed in parallel.


Sure, and that's why we recommend that in THIS case, you would probably build a separate module (or use standard RPMs) instead.
 
> So, when we started looking at ways to provide alternative software, we
> determined that parallel-installation was a non-goal. Not needing to solve
> an unsolvable problem meant that we could focus on the parts that really
> matter: allowing people to select which single version of the software
> meets their needs.

So the conclusion is that inability to have parallel-installable streams
of the same module is not due to technical difficulties to implement
that feature, but rather a consequence of prioritizing different
requirements.


You drew a conclusion that is EXACTLY the opposite of what I said above. We determined that parallel-installation was basically impossible to build in a generic way. Once that was eliminated as a possible requirement, the rest fell into place fairly neatly.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/IUE4AYMCCIFI74STTB45GVCK6Y24VU2T/

[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