stripping leading './' creates broken archives when used with deps.

[thesayyn]

pkg_tar creates broken archives when any of the deps contain entries with leading ./ in their path.

Imagine a tar file that is downloaded via http_archive with leading ./ path entries

./var/
./var/backups/
./var/cache/
./var/lib/
./var/lib/dpkg/
./var/local/
./var/lock/
./var/log/
./var/run/
./var/spool/
./var/tmp/
./etc/os-release

A BUILD file that looks like this;

pkg_tar(
  srcs = [
     "./var/lib/dpkg/somefile"
  ],
  deps = ["@label/to/downloaded_archive"]
)

The resulting archive that pkg_tar creates, in this case, looks like the below;

./var/cache/
./var/lib/
./var/lib/dpkg/
var/
var/lib/
var/lib/dpkg/
var/lib/dpkg/status.d/
var/lib/dpkg/status.d/base-files
var/lib/dpkg/status.d/base-files.md5sums

This semantically corrupt archive as there are two entries for var/lib/dpkg/. var/lib/dpkg/ and ./var/lib/dpkg/ is the same from the extractor tools standpoint.

Ideally, I'd expect pkg_tar to have no opinion about what leading path the entries have but I guess that's not an option anymore.

If that's the case pkg_tar should be fixing the deps as well to produce semantically correct archives.

[thesayyn]

@aiuto this affects distroless repository. I have time to create a PR here. Not sure what should be the fix here though.

I have tried adding a post process action to some of our targets but that leads to longer build time in some of the larger targets.

I feel like the principled fix here is to not have pkg_tar strip leading slashes.

What do you think?

[aiuto]

The leading './' is a mistake. I would rather hack up deps to strip the './' as well. Since future work will be to eliminate deps in favor of richer semantics, I don't worry so much about hacks there.

[thesayyn]

The leading './' is a mistake.

could you elaborate on this a bit more? This is the standard way all the Debian packages are distributed.