Provide .tar.gz/xz Linux package instead of .zip

[Tyriar]

Programs typically offer .tar.gz packages instead of zips on Linux.

[Lindenk]

As long as a standard compressed build is provided (as it currently is as a .zip achive), a package can be easily maintained by the Arch Linux community. The package is located here though and, if there are any breaking changes to the way vscode should be installed, leaving a comment or contacting the maintainer of the package would be helpful.

Also, as someone has pointed out in the comments for the package, building from source would be prefered by some members of the community and if there would be any problems in doing so pointing them out would also be helpful.

[Tyriar]

@Lindenk unfortunately some of our build process needs to remain closed at least for the time being as it integrates with our private CI system and build servers. Since it's an electron app however, building from source is primarily just minifying and optimizing javascript (using a bunch of npm modules). I'm curious about the reasons people would want to be able to build from original source when pretty much all of it is available at https://github.com/Microsoft/vscode?

I'll be sure to ping you if I fiddle with things that may affect the package.

[kevr]

The reason people would like to build from original source is to use different options for a build, and to target specific architectures or toolchains. There may be an architecture that you have not built for that somebody wishes to maintain the project for.

[Tyriar]

@kevr related: #6442 :P

Thanks for the explanation, I'll see if we can improve the situation.

[dcelasun]

Hi, I'm the maintainer of the linked Arch Linux package. I actually prefer the official zip archive, it lets me avoid lots of unnecessary build dependencies. There is also another package that builds from source; some people seem to prefer that.

Anyway, the current zip file is fine but as @Lindenk said, if you could somehow publish a list of breaking changes before release, that would be great. In the past, various binaries and images moved directories or went from upper case to lower case without any heads up and it broke the PKGBUILD.

[Tyriar]

Thanks for chiming in @dcelasun, I wasn't aware of the Arch Linux package until now so it was impossible to notify you :P

I think this issue will go towards solving the issue of notification as after these discussion I'd like to do the following:

1. Distribute a .tar.gz package and deprecate the Linux .zip (as per platform conventions)
2. Create a .pkg.tar.gz so that your PKGBUILD can defer the installation logic to the .INSTALL

That way the vscode repository contains the logic for installing on Arch Linux, so I'll be able to change it and test if there are refactors, new post install steps, etc. This will also save a bunch of duplication on your part if you wanted to support the insiders build too. @dcelasun I'm interested in your thoughts on this plan.

FYI the improving open source builds discussion is captured in #3029

[dcelasun]

+1 on switching to tar.gz, zip files always felt alien on Linux.

However, I think 2 is a bad idea. Not only it would increase maintenance burden on your end, it would also make it less flexible for distros. For example, Arch's packaging conventions differ from most distros and the filesystem layout is a bit different as well. Keeping up with such changes (which are not infrequent with Arch) should be on distro maintainers.

What I would suggest, is an official packaging changelog that gets published a few days before every release. Something like:

• Version 2016.2
  • foo.bin moved from foo/bar to /foo/bar/bin
  • Code.png renamed to code.png
  • New feature X needs dependency Y

This would not only provide us with a heads up, but also help keep track of what changed and when. Does this sound feasible at all? If not, at the very least an unofficial tarball a few days before release would give us some time update the PKGBUILD and fix any potential breakage.

[Tyriar]

@dcelasun 👍 good points :)

Would the log for ./resources/linux be sufficient to check for required package changes? This contains the the metadata and post/pre install script files for the deb and rpm packages.

[dcelasun]

Yep, that seems good to me 👍

[Tyriar]

.tar.xz might be a better way to go, 30% file saving for significantly slower compression time and slightly slower decompression time.

❯ time tar -cJf vscode.tar.xz VSCode-linux-x64/

real    0m48.358s
user    0m48.396s
sys 0m0.276s

❯ time tar -xJf vscode.tar.xz

real    0m2.161s
user    0m2.172s
sys 0m0.180s

❯ time tar -czf vscode.tar.gz VSCode-linux-x64/

real    0m4.808s
user    0m4.732s
sys 0m0.148s

❯ time tar -xzf vscode.tar.gz

real    0m0.845s
user    0m0.800s
sys 0m0.164s

❯ ls -l --block-size=M
...
-rw-rw-r--  1 daniel daniel 44M May 19 22:36 vscode.tar.gz
-rw-rw-r--  1 daniel daniel 31M May 19 22:35 vscode.tar.xz

[Tyriar]

Fixed, coming in June release.