Produce bare tarballs (not gzipped) on `zpm bundle`

[larsbutler]

In order to make zapps more easily consumable directly by ZeroVM, it would be useful to not gzip .zapp files. As far as I can tell, ZeroVM cannot directly mount a .tar.gz. However, you can mount a zapp directly (using zvsh --zvm-image, for example) if the file is just a tar.

[rpedde]

I agree that if zapps are zerovm system images, then it probably doesn't make sense to gzip them.

[pkit]

Zerocloud supports .gz stuff, but the main idea of gz, I think, was to save traffic when uploading stuff

[larsbutler]

@pkit Yep, that's right. But if we run zapps locally, they can't be gzipped.

This is kind of my vision: to bridge the gap between "images" and "zapps". They're already so close. I would consider python.tar to be a zapp, and I would like to have it in the ZPA. For example.

[mgeisler]

@rpedde

I agree that if zapps are zerovm system images, then it probably doesn't make sense to gzip them.

I would suggest that zerovm should just decompress them on the fly. I'm sure we can put gzip into ZRT and let it decompress the image too when it loads it.

[larsbutler]

Long term, it would good to have gzip support in ZeroVM. But for now, I think we can do without zipping. Assuming everyone actually agrees with treating system images and zapps as the same thing. Which not everyone does, apparently.

[mgeisler]

I don't like using the same file extension for files that are both compressed (on your system) and uncompressed (when deployed into Swift).

However, I just took a look at the python.tar to get a real-world example. Compressing it with gzip brings the size down from 70 MB to 19 MB. That is a much bigger saving than I had expected and this makes me want to push for adding gzip support to ZRT even more.

Maybe @pkit and @YaroslavLitvinov can comment on the feasibility of making zerovm and ZRT transparently decompress a system image when it is loaded? I haven't really worked with gzip in C, but it is my understanding that it is very easy to use.