Preserve leading "./" in paths for Debian package compatibility#51
Open
vrmiguel wants to merge 1 commit intoastral-sh:mainfrom
Open
Preserve leading "./" in paths for Debian package compatibility#51vrmiguel wants to merge 1 commit intoastral-sh:mainfrom
vrmiguel wants to merge 1 commit intoastral-sh:mainfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi @charliermarsh, congrats on the project!
This PR suggests fixing
Header::set_path's 'incorrect' behavior of stripping away the leading dot-slash in paths.The reasoning for this is that Debian/Ubuntu packaging (
.debs) require their data tarballs to state their entries as follows:The current
tar-rsprocessing instead converts those into:The lack of leading dot-slash in the files above makes Debian tooling (
apt/dpkg) to extract files in the incorrect folders, or reject the .deb entirely (now I can't recall for sure)This has been a known
tar-rsissue for years, described in issues such as alexcrichton/tar-rs#263 and alexcrichton/tar-rs#335, but we haven't had much luck in hearing back from Alex, so I suppose it's better to try to fix this here, downstream