On Thu, Jan 30, 2014 at 6:37 PM, Val Markovic <[email protected]> wrote:
> I'll second Armin and Corey here; if lib A and B depend on different > versions of lib C, you *must* still be able to easily build and link them > together as deps of lib D. This is *critical* in large codebases > I would personally say having a dependency resolver is *critical* to large codebases (or any system with a large number of potentially conflicting packages, like an OS) > where it's not feasible to go into A and B and update which version of C > they depend on since A & B are possibly very big and have tons of other > users who aren't as willing as you are to switch to a new version of C. > How does dependency resolution even work in this many-versioned world? Do you just abandon it entirely? If lib A depends on lib C 1.0.0 and lib B depends on lib C 1.0.1, do you install both? Or can you find a solution where both lib A and lib B are happy with one particular version of lib C? This sort of problem is typically solved by toposorting your way through a set of constraints, but how do you even specify constraints where there may be mutually compatible versions, but there may not be? At what point can you pick one version of lib C as opposed to two or three or more? For that matter, how do you even resolve dependencies in this sort of world? What algorithm do you use? And now imagine a (frighteningly common) nightmare scenario, where the > library version clash is not two steps away from you, but say 8 and 12. So > you link something that depends on something that depends on something ... > that 8 steps away depends on A (which depends on C v1), and a different > chain of deps that 12 steps away depends on B (which depends on C v2). Good > luck resolving that. > Yes, these situations suck. In the cases where people do actually want to have two different major versions of a piece of software installed simultaneously, the convention I've typically seen is to add a "2" or "3" to the end of the package name. It's a bit silly, but certainly not irresolvable. I also don't think this comes up in practice as you allege. Perhaps it's more frequent in systems that don't have a dependency resolver... -- Tony Arcieri
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
