using tar.bz2 for releases instead of .bz2 to preserve permissions.

[gavinwy]

Currently restic uses bz2 files of the binaries for the releases on GitHub. bz2 clobbers file permissions, including executability, resulting in an extra step of having to chmod the binary after extracting but before running it. This is the first time I've seen compressed software like this, where the binary isn't wrapped in tar before compression and distribution. I'm just wondering why releases are packaged like this and/or if there was a discussion about it at some point. Thanks!

[fnkr]

This might be out of scope, but if packaging is changed anyway, it might be a good idea to switch from .bz2 to .tar.xz. The archive would be smaller and decompression faster.

[thefirstofthe300]

As a saltstack user installing restic from Github, I second this motion since it would also make state management a lot easier. Saltstack doesn't support decompressing a bz2 compressed file using the archive module (since bz2 isn't an archive). Instead, I have to download and decompress the file myself.

[MichaelEischer]

The current packaging using just .bz2 makes it easy to reproducibly create the release binaries. To use .tar.bz2 we'd need a way to deterministically generate the tar file.

Regarding the compression method, we'd probably also want to consider this comment: #2705 (comment)

[beatbrot]

I have the exact same issue with Ansible as @thefirstofthe300 has with saltstack

[rwolfson]

The current packaging using just .bz2 makes it easy to reproducibly create the release binaries. To use .tar.bz2 we'd need a way to deterministically generate the tar file.

If it's of use, this reference page includes some flags you can add to tar to help make the output more deterministic, including overriding file modification timestamps and specifying file order.

https://reproducible-builds.org/docs/archives/