Yarn: Warnings when extracting the source tarball (tar: Ignoring unknown extended header keyword 'SCHILY.dev')

[artberri]

Do you want to request a _feature_ or report a _bug_?

Not exactly a bug but a little issue.

What is the current behavior?

When downloading the source and extracting the tar.gz (tar zvxf latest.tar.gz) on Linux machines it ouputs some warnings:

dist/node_modules/console-control-strings/package.json
tar: Ignoring unknown extended header keyword 'SCHILY.dev'
tar: Ignoring unknown extended header keyword 'SCHILY.ino'
tar: Ignoring unknown extended header keyword 'SCHILY.nlink'
dist/node_modules/console-control-strings/README.md
tar: Ignoring unknown extended header keyword 'SCHILY.dev'
tar: Ignoring unknown extended header keyword 'SCHILY.ino'
tar: Ignoring unknown extended header keyword 'SCHILY.nlink'
dist/node_modules/console-control-strings/README.md~
tar: Ignoring unknown extended header keyword 'SCHILY.dev'
tar: Ignoring unknown extended header keyword 'SCHILY.ino'
tar: Ignoring unknown extended header keyword 'SCHILY.nlink'
dist/node_modules/concat-map/.travis.yml
tar: Ignoring unknown extended header keyword 'SCHILY.dev'
tar: Ignoring unknown extended header keyword 'SCHILY.ino'
tar: Ignoring unknown extended header keyword 'SCHILY.nlink'
dist/node_modules/concat-map/example/
tar: Ignoring unknown extended header keyword 'SCHILY.dev'
tar: Ignoring unknown extended header keyword 'SCHILY.ino'
tar: Ignoring unknown extended header keyword 'SCHILY.nlink'
dist/node_modules/concat-map/index.js
tar: Ignoring unknown extended header keyword 'SCHILY.dev'
tar: Ignoring unknown extended header keyword 'SCHILY.ino'
tar: Ignoring unknown extended header keyword 'SCHILY.nlink'
dist/node_modules/concat-map/LICENSE
tar: Ignoring unknown extended header keyword 'SCHILY.dev'
tar: Ignoring unknown extended header keyword 'SCHILY.ino'
tar: Ignoring unknown extended header keyword 'SCHILY.nlink'
dist/node_modules/concat-map/package.json
tar: Ignoring unknown extended header keyword 'SCHILY.dev'
tar: Ignoring unknown extended header keyword 'SCHILY.ino'
tar: Ignoring unknown extended header keyword 'SCHILY.nlink'

If the current behavior is a bug, please provide the steps to reproduce.

Just follow the installation instructions on a Linux machine:

cd /opt
wget https://yarnpkg.com/latest.tar.gz
tar zvxf latest.tar.gz

What is the expected behavior?

Those warnings should not appear if you create the tarball with the GNU tar tool. Here you have some info about how to install it on a mac:
http://superuser.com/questions/318809/linux-os-x-tar-incompatibility-tarballs-created-on-os-x-give-errors-when-unt

Please mention your node.js, yarn and operating system version.

Tested on an Ubuntu 16.04 machine.

[Daniel15]

cc @kittens - We should keep this in mind if we ever need to build a tarball on Mac OS again (use GNU tar rather than BSD tar). Shouldn't be an issue for most of our releases as we'll build on Linux.

@artberri - Out of curiosity, is there a reason you're using the tarball rather than the Ubuntu package? Just out of preference, or testing things out, or are there limitations with the package?

[artberri]

@Daniel15 The Ubuntu package works fine for me. I'm testing the different installation methods because I'm creating a Puppet module for Yarn.

You've done a great job with Yarn, my project builds and my releases will speed up a lot with this :+1:

Side question: Can I assume that you will keep the tarball format? I mean, Will it include always a dist folder on it?

[artberri]

Here you can see the module that I've built:
https://forge.puppet.com/artberri/yarn

[rstacruz]

it seems extracting yarn via tar on linux is slow; i've experienced this when installing yarn on Semaphoreci.

[Daniel15]

This will be fixed in the next release as it'll be built on Linux using GNU tar.

[sockmonk]

In order to create a tarball in OSX, but extract it on linux, you need to add this keyword to the extraction path (using the default GNU tar):

tar --warning=no-unknown-keyword -zxf my_archive.tar.gz

[Daniel15]

This was fixed a long time ago. Tarballs are now only built via CI using GNU tar and thus don't have this issue.