tarball.sh.tpl: add nlink=1 to mspec

[dmivankov]

Mitigates buildbarn/bb-remote-execution#162 while libarchive/libarchive#2587 isn't released yet.

OCI layout should be deduplicated already as blobs are stored content-addressable, so setting nlink=1 to disallow detection and creation of hardlinks within tarball should be safe

[thesayyn]

Hmm ı wonder if this would have any interesting side effects, perhaps when fuse is involved?

[dmivankov]

I think the only effect is not attempting to match dev+inode between files in archive that's being created and not storing matches as tar hardlinks in produced tarball. Since for OCI images there shouldn't be matches, any correctly-produced archives should stay the same and unpacking them wouldn't know if nlink=1 option was applied or not

[dmivankov]

3.8.0 is now released https://github.com/libarchive/libarchive/releases/tag/v3.8.0

But not yet in https://github.com/bazelbuild/bazel-central-registry/tree/main/modules/libarchive (I assume that where prebuilt bsdtar comes from).

Updating libarchive should resolve the issue with remote execution, but nlink=1 still might be a valid change to do

[thesayyn]

Yes, somebody actually needs to go release that. @alexeagle was driving a release train, he could probably help with this.

[alexeagle]

I'm hoping to get some help on bazelbuild/bazel-central-registry#4649

[thesayyn]

@dmivankov now that tar.bzl has a new release, do you think this is still important?

[dmivankov]

If it is already the default in latest rules_oci release it'd be less important to apply nlink=1 yes

[thesayyn]

I believe the principled fix is to depend on tar.bzl since it uses the fixed version of libarchive; https://github.com/bazel-contrib/tar.bzl