/*Adam Samalik*/ wrote on Fri, 9 Jun 2017 08:50:58 +0200:
On Thu, Jun 8, 2017 at 10:49 PM, Randy Barlow
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
> 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
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
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).