[rust-dev] Deprecating rustpkg

Vladimir Lushnikov vladimir at slate-project.org
Fri Jan 31 16:07:47 PST 2014

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 <bascule at gmail.com> wrote:

> On Fri, Jan 31, 2014 at 3:59 PM, Jack Moffitt <jack at metajack.im> 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
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140201/e939142f/attachment-0001.html>

More information about the Rust-dev mailing list