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/
