Adam Samalik wrote on Fri, 9 Jun 2017 08:50:58 +0200:

On Thu, Jun 8, 2017 at 10:49 PM, Randy Barlow <> wrote:
On Thu, 2017-06-08 at 22:17 +0200, Adam Samalik wrote:
> You add the package and other people start to use it. That's great
> until you need to change the version, but can't, because other people
> started to use it as a dependency and it would break their stuff.

I recently heard that it will be impossible to install two packages
that depend on different versions of a dependency at the same time. For
example, if package A depends on C < 2.0 and package B depends on C >=
2.0, it will be impossible to install A and B on the same system. Is
this true? If so, I worry that we will see fracturing in Fedora as
packages drift apart in their dependencies. If not so, I apologize for
the noise ☺

I would say it's "half truth" right now. :-)

There has been no extra work on changing RPMs. If something conflicts now, it will keep conflicting. But!

So, not everything will probably be installable as RPMs on the same system at the same time. But I see the world is going to containers, and I'm thinking if not being to install all RPMs next to each other on a single system is still a real problem. Thoughts? 

Actually, I think the Modularity work can (potentially) provide a solution for installing multiple versions of the same package for RPM (assuming that the packages are properly packaged so that different versions don't conflict with each other, e.g. two versions of a library like boost).
For example, library versioning makes it possible to install multiple versions of the same library in a system. However, RPM doesn't allow it (except that you use a different package name for them, so they are NOT the same package in RPM's view) except for kernel as an exception. IIRC, one of the reasons for this is that RPM doesn't know how to handle updates of that package. (e.g. there are foo-1 & foo-2 installed, and now foo-3 is available. What happen when you try to update foo?). For kernel, it is never updated. New versions are just installed.

However, if Modularity becomes a first class citizen for RPM/DNF, it is possible to solve this problem too. You know that you should install (if possible!) different versions of the same package simultaneously if they are required by different modules, and you know that a new version of the package in a module should update the previous version of the package from that module.

But, well, using containers and things like FlatPack/Snappy, such complexity might seem not necessary. But going that way, the Modularity itself maybe also can be replaced largely with them too (the only missing peace I can think of right now is when you need an Apache version which is newer than that of CentOS/EPEL, but older than that of not EOL-ed Fedora releases).