<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 12, 2018 at 10:58 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Mon, Feb 12, 2018 at 10:06 PM, Vlad Dumitrescu <<a href="mailto:vladdu55@gmail.com">vladdu55@gmail.com</a>> wrote:<br>> On Mon, Feb 12, 2018 at 9:06 PM, Jesper Louis Andersen<br>
> <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.<wbr>com</a>> wrote:<br>>> Using a cryptographic checksum for a package and then pointing the name to<br>
>> the checksum would have saved Node.js npm package manager a lot of headaches<br>
>> when people remove, rename or otherwise destroy packages.<br>
>> It also allows you to comply with legal requests with a sunset period. As<br>
>> in "I hear you, and the name will be given to you. But we give people 6<br>
>> months time to upgrade before we remove the old checksummed packages".<br>
>> I'm interested in why someone did not try this yet. Or if one tried, why<br>
>> it didn't work out. It seems very obvious to build a<br>
>> content-addressable-store for your packages.<br>
><br>
><br>
> I'm not sure I understand this completely. Using the checksum of a package<br>
> as identifier is IMHO only useful if it is used in the dependencies list of<br>
> other packages. If the deps list uses names (and people will use names<br>
> anyway, not checksums), then the problem remains that in case a package is<br>
> renamed and another one reuses the name, we don't know to which one a<br>
> reference points.<br>
<br>
</span>The dependency list should be a list of checksums and NOT a list of<br>
names - this list of<br>
checksums has itself a checksum (the "true" name of the package).<br>
<br>
A human readable name is just an alias to a checksum - two different<br>
human readable names<br>
are the "same" if they are aliases to the same checksum.<br>
<br>
Basically files should be named by their checksums - for fairly<br>
obvious reasons of<br>
convenience tools should hide or reveal these names when necessary or<br>
appropriate.<br>
<br>
For a given content the checksum is unique.<br>
<br>
To handle renamings you just need a lookup table of<br>
<br>
      {Name, Time, Checksum} tuples that tracks changes to the name of<br>
the checksum over time<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Thanks for the explanation, I understand the mechanics, but not the "real world usage".</div><div><br></div><div>* A checksum referes to a {package_name, time} tuple, so there is no way to refer to the package in general. Except by its name.</div><div><br></div><div>* Even if there was, nobody is going to say "For a gizmo processing library, we have to choose between B17556DB683000BA50370B16C0619DF1337E7AF7ECBF7D64FBF8D1D6BCE3109B and 7ACC7D785B5ABE8A6E9ADBDE926A24E481F29956DD8B4DF49E3E4E7BCC92A018, which one is better?" So people will use names. </div><div><br></div><div>* Now the project is presumably configured in a file, written by a programmer - again the name will be used. The hash can be retrieved and stored by the build tool, so that we get a hard reference...</div><div><br></div><div>* ... which is exactly what rebar and mix do with <a href="http://hex.pm">hex.pm</a> (if I get it right), except they use the version string instead of timestamp. So if <a href="http://hex.pm">hex.pm</a> keeps track of timestamps and of historical mappings between names and hashes, then it's done!</div><div><br></div><div>* However, the imprecision of using names remains because we're humans. Tools already use hashes.</div><div><br></div><div>Am I misunderstanding something?</div><div><br></div><div>best regards,<br></div><div>Vlad</div><div><br></div><div> </div></div></div></div>