Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add hash characters to tarball file name and extracted package directory name #5079

Closed
kalefranz opened this issue Apr 19, 2017 · 9 comments
Closed
Assignees
Labels
locked [bot] locked due to inactivity source::governance created by members of the conda governance (https://github.com/conda-incubator/governance) type::feature request for a new feature or capability

Comments

@kalefranz
Copy link
Contributor

Append the first 5 characters of the tarball md5 hash to the tarball file name when it's written to the package cache. Also use the same file name (i.e. with the appended md5 characters) as the extracted package directory name.

To clarify, for the tarball file name, the hash should be appended to file name root, before the .tar.bz2 extension. So if the hash characters a1b2c for the file cryptography-1.5.3-py27_0.tar.bz2, the filename written to the cache should be cryptography-1.5.3-py27_0-a1b2c.tar.bz2 and the extracted directory name should be cryptography-1.5.3-py27_0-a1b2c.

I think the - separator is correct here. If it causes a problem with people string parsing file names for information they should be getting from metadata anyway, ¯\_(ツ)_/¯.

@kalefranz kalefranz added source::governance created by members of the conda governance (https://github.com/conda-incubator/governance) type::feature request for a new feature or capability labels Apr 19, 2017
@stefanseefeld
Copy link
Contributor

Wouldn't the md5 checksum of a tarball change if its content (including the names of the contained files) change ? Isn't that a catch-22 ?

@stefanseefeld
Copy link
Contributor

(Just verified: it does indeed.)

@stefanseefeld
Copy link
Contributor

This works if the package directory name only gets the hash added after it has been extracted.

@nehaljwani
Copy link
Contributor

I would vote for '#' as a separator :-), like: cryptography-1.5.3-py27_0#a1b2c

@kalefranz
Copy link
Contributor Author

Interesting suggestion @nehaljwani. @msarahan, @mingwandroid Any thoughts?

@msarahan
Copy link
Contributor

I'd be in favor of # as well. Please do not toss the importance of content after - until we are 90% certain that it's OK - i.e. we've tried it and dogfooded it internally for at least a couple of weeks.

This # notation would not interfere with the conda-build package hashes, so it would be fine. However, I wonder how much this hash filename addition would be necessary once people move to using conda-build 3.

@stefanseefeld
Copy link
Contributor

AFAIU, the only remaining opportunity for collision comes from multiple channels and different subdirs providing the same package (file) names. I'd actually be in favour of reproducing those two axes in our local package cache directory structure. (An added benefit is that it is more transparent to the naked eye.)

@kalefranz
Copy link
Contributor Author

I think we should hold off on this for now, since it could potentially complicate the problems we're already/still having with metadata hot fixes. Going to close it for now. We can bring it back some point in the future if needed. FWIW, I liked # too.

@github-actions
Copy link

github-actions bot commented Nov 1, 2021

Hi there, thank you for your contribution to Conda!

This issue has been automatically locked since it has not had recent activity after it was closed.

Please open a new issue if needed.

@github-actions github-actions bot added the locked [bot] locked due to inactivity label Nov 1, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked [bot] locked due to inactivity source::governance created by members of the conda governance (https://github.com/conda-incubator/governance) type::feature request for a new feature or capability
Projects
None yet
Development

No branches or pull requests

4 participants