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.
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.
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.
[1] I can't install two packages that try to serve the same well-known D-BUS name or both provide a local DNS cache, for example. I can't install two packages that both own the same executable name without using the "alternatives" system. I can't install two versions of a package that provide a shared object plugin with the same name. And so on and so forth.
All of these have possible solutions, but no single generic solution exists. In the general case, we figure that the triumvirate of modules, containers and VMs solves this problem for 99% of cases. The remaining exception cases have to be dealt with individually.
_______________________________________________ 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/QPBLGCRRG2XRV4GRKUGTL35CGM7KSYFX/
