On Thu, Jun 21, 2018 at 11:56 AM Mikolaj Izdebski <mizde...@redhat.com> wrote:
> On 06/20/2018 04:15 PM, Stephen Gallagher wrote: > > On Wed, Jun 20, 2018 at 10:06 AM Mikolaj Izdebski <mizde...@redhat.com> > > 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/IUE4AYMCCIFI74STTB45GVCK6Y24VU2T/
