On Fri, Jan 31, 2014 at 3:59 PM, Jack Moffitt <[email protected]> wrote:
> The algorithm here is rather simple. We try to satisfy rust-logger and > rust-rest. rust-rest has a version (or could be a tag like 1.x) so we > go get that. It depends on rust-json 2.0 so we get that. Then we try > to look for rust-logger, whatever version is latest (in rustpkg this > would mean current master since no version or tag is given). This > pulls in rust-json 1.0 since 1.0 != 2.0 and those have specific tags. > Everything is built and linked as normal. Whether rust-json's > constraints are exact revisions or they are intervals (< 2.0 and >= > 2.0 for example), makes little difference I think. To reiterate, it sounds like you're describing every package pinning its dependencies to a specific version, which I'd consider an antipattern. What is to prevent a program using this (still extremely handwavey) algorithm from depending on rust-json 1.0, 1.1, 1.2, 1.3, 1.4, 2.0, 2.1, and 2.2 simultaneously? What if some of these are buggy, but the fixed versions aren't used due to version pinning? What if rust-json 1.0 has a security issue? -- Tony Arcieri
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
