The feature of golang having source in a project path with "internal"
makes the code only able to be imported by the project itself.
https://docs.google.com/document/d/1e8kOo3r51b2BWtTs_1uADIA5djfXhPT36s6eHVRIvaU/edit?tab=t.0
Since we have this carried version of `archive/tar` with our byte
accounting patches, it is also means the version of archive/tar has not
kept up with upstream.
our tar-split libraries do not even utilize all the function calls of
our carried archive/tar, so might as well limit anyone else in the world
from calling them as well.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
This allows reading the metadata contained in tar-split
without expensively recreating the whole tar stream
including full contents.
We have two use cases for this:
- In a situation where tar-split is distributed along with
a separate metadata stream, ensuring that the two are
exactly consistent
- Reading the tar headers allows making a ~cheap check
of consistency of on-disk layers, just checking that the
files exist in expected sizes, without reading the full
contents.
This can be implemented outside of this repo, but it's
not ideal:
- The function necessarily hard-codes some assumptions
about how tar-split determines the boundaries of
SegmentType/FileType entries (or, indeed, whether it
uses FileType entries at all). That's best maintained
directly beside the code that creates this.
- The ExpectedPadding() value is not currently exported,
so the consumer would have to heuristically guess where
the padding ends.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
