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

Do not use gnu sparse extension please! #87

Closed
NobodyXu opened this issue Aug 19, 2022 · 8 comments
Closed

Do not use gnu sparse extension please! #87

NobodyXu opened this issue Aug 19, 2022 · 8 comments

Comments

@NobodyXu
Copy link
Member

NobodyXu commented Aug 19, 2022

tar does not support gnu sparse extension alexcrichton/tar-rs#295 , thus cargo-binstall cargo-bins/cargo-binstall#177 also does not support it.

cargo-deb-1.38.4-x86_64-unknown-apple-darwin cannot be extracted properly using tar (see this repository for reproduction).

@NobodyXu
Copy link
Member Author

cargo-asm-0.1.16-aarch64-apple-darwin also failed with the same error.

@alsuren
Copy link
Collaborator

alsuren commented Aug 19, 2022

if we want to fix this on the quickinstall end, we would need to:

  • find a setting for bsd tar that builds tarballs that are compatible with the rust tar library, and start using it in the build scripts
  • make a list of "broken" packages
    • download all tarballs from the quickinstall archives (you can get the names by running git tag in this repo)
    • run a
  • delete all of the "broken" packages
    • NOTE: I would like to eventually enforce that if I ever upload a package to $URL then the checksum of the package at $URL will never change. This isn't currently enforced in code, but I'd like to avoid doing it anyway. If we manually delete a package then it should stay deleted.
    • it might be enough to delete the tag and then re-create it without the assets (so that future builds will fail), but that feels like bad practice. If the is an easy way to batch-delete release assets via the GitHub api then that would be preferred.

It will probably be simpler and quicker to fix it on the binstall end.

It's worth noting that bsd tar doesn't have any problem unpacking these archives.

The tarballs are typically tiny, with a very small number of files, so you could just shell out to tar -xOzf - $bin_name multiple times (see https://www.gnu.org/software/tar/manual/html_node/Writing-to-Standard-Output.html), passing the tarball into stdin and reading the extracted file from stdout.

@NobodyXu
Copy link
Member Author

NobodyXu commented Aug 19, 2022

find a setting for bsd tar that builds tarballs that are compatible with the rust tar library, and start using it in the build scripts

I would like this to be applied as a temporary workaround, while I spend time investigating on how to fix the issue in tar or trying to get attention from others.

It will probably be simpler and quicker to fix it on the binstall end.

Well, the maintainer of tar isn't very active and there isn't many people that care about the issue I raised there either alexcrichton/tar-rs#295 .

Plus, I was not that familiar with tar format, so it might take quite some time before a proper fix in tar to land.

so you could just shell out to tar -xOzf - $bin_name multiple times (see https://www.gnu.org/software/tar/manual/html_node/Writing-to-Standard-Output.html), passing the tarball into stdin and reading the extracted file from stdout.

That will add an external runtime dependency to cargo-binstall, which we are trying our best to avoid.

@alsuren
Copy link
Collaborator

alsuren commented Aug 19, 2022

find a setting for bsd tar that builds tarballs that are compatible with the rust tar library, and start using it in the build scripts

I would like this to be applied as a temporary workaround, while I spend time investigating on how to fix the issue in tar or trying to get attention from others.

We can certainly do this to avoid creating more files that binstall doesn't understand. Do you know which flags we need to produce lowest-common-denominator tar output?

@NobodyXu
Copy link
Member Author

find a setting for bsd tar that builds tarballs that are compatible with the rust tar library, and start using it in the build scripts

I would like this to be applied as a temporary workaround, while I spend time investigating on how to fix the issue in tar or trying to get attention from others.

We can certainly do this to avoid creating more files that binstall doesn't understand. Do you know which flags we need to produce lowest-common-denominator tar output?

Reading through the man page of tar, I think this might help:

       -H, --format=FORMAT
              Create archive of the given format.  Valid formats are:

              gnu    GNU tar 1.13.x format

              oldgnu GNU format as per tar <= 1.12.

              pax, posix
                     POSIX 1003.1-2001 (pax) format.

              ustar  POSIX 1003.1-1988 (ustar) format.

              v7     Old V7 tar format.

       --old-archive, --portability
              Same as --format=v7.

       --posix
              Same as --format=posix.

@NobodyXu
Copy link
Member Author

@alsuren I think --format=posix/--posix might work.

@NobodyXu
Copy link
Member Author

@alsuren I just found this PR alexcrichton/tar-rs#298 , I'm afraid we might need to use the old v7 tar format by passing --portability.

@NobodyXu
Copy link
Member Author

This issue is closed as quickinstall already disables gnu sparse extension and cargo-binstall has picked up support for gnu sparse extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants