Then you would want to know about it. No package manager for a language has a way to see security advisories (and this is a problem). Gentoo has GLSA which is kind of OK (better than scanning the CVE list yourself) but I feel a language should offer a tool to do exactly this.
Just to be clear, I think what you are saying is that you want version pinning to be dynamic? I.e. when a new version of a library dependency becomes available, upgrade the package with that dependency? On Sat, Feb 1, 2014 at 12:03 AM, Tony Arcieri <[email protected]> wrote: > 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
