-
Notifications
You must be signed in to change notification settings - Fork 25
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
Support systems with very old tar implementations. #228
Comments
Ah. Looks like bsdtar can be coerced into emitting a diagnostic on filenames that are too long, but, but it looks like it creates a tarball with truncated filenames and worse, doesn't exit with an error:
|
You will need something like macro => { TARFLAGS => "--format=ustar -c -v -f" }, in your |
@Tux Please try: https://cpan.metacpan.org/authors/id/P/PL/PLICEASE/Alien-Build-2.31_01.tar.gz This identifies as simply
If this works, then it looks like as a workaround I can use If this doesn't work then it would be helpful to find a way to reproduce this error using Free or OpenSource tools, as like most people I do not have access to HP-UX machines. A way to reproduce this using Free or OpenSource tools may also help when reporting this to |
|
Waiting for a response |
This should be resolved in 2.32 as workarounds have enacted in the release process while we wait for Dist-Zilla or Archive-Tar-Wrapper to respond. @Tux please open issues for the other test fails you were seeing on HP-UX. If you can provide the verbose output ( |
Systems that use the "original" tar v7 format cannot grock the tarball produced by AB, because it has files with paths longer than 99 characters.
https://www.gnu.org/software/tar/manual/html_section/tar_67.html
HP-UX is apparently an affected system. I think just making the paths shorter should allow GNU tar to produce tarballs that the affected systems can read. If so then we should make the paths shorter, and add a test to ensure that paths are kept under 99 characters long. Can double check by trying to create a tarball with the
--format v7
option with GNU tar. Supplying this option to a read of the tarball with GNU tar doesn't seem to reproduce the error seen on HP-UX.The text was updated successfully, but these errors were encountered: