Is it possible at all to find the latest version of a library which is still compatible completely automatically? Incompatibilites can be present on logic level, so the compilation wiith incompatible version will succeed, but the program will work incorrectly. I don't think that this can be solved without assumptions about versioning (like semver) and/or without manual intervention.
Couldn't we just use more loose variant of version pinning inside semantic versioning, with manual user intervention when it is needed? For example, assuming there is something like semantic versioning adopted, packages specify dependencies on certain major version, and the dependency resolver downloads latest available package inside this major version. If for some reason automatically selected dependency is incompatible with our package or other dependencies of our package, the user can manually override this selection, maybe even with another major version. This is, as far as I understand, the system of slots used by Portage as Vladimir Lushnikov described. Slots correspond to major versions in semver terms, and other packages depend on concrete slot. But the user has ultimate power to select whichever version they need, overriding automatic choice. In short, we allow dependency resolver to use the latest possible packages which should be compatible according to semantic versioning, and if it fails, we provide the user with ability to override dependency resolver choices. 2014-02-01 Tony Arcieri <[email protected]>: > 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 > _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
