Ludovic Courtès <[email protected]> writes: >> Otherwise, `git-archive(1)' is flexible enought to do a lots of things. > > Yeah and it emits plain tar, so one can use whatever compressor they > want. > > My question in the context of this thread is whether BLUE might end up > recreating ‘make dist’, which is convenient in many ways but leads > people to distribute tarballs that contain pre-built artifacts. > > I think we should try to discourage tarballs that contain pre-built > artifacts. In practice, if one is expected to have BLUE installed to > build a given package, a tarball doesn’t bring much anyway compared to a > VCS checkout.
Having a 'make dist' mechanism in BLUE that produce tarballs identical to git-archive outputs seems fine (for projects hosted in git). If it would add other files I would worry, as that seems to re-invent the autoconf 'make dist' approach that we should (try to) get away from. I believe a tarball do bring value compared a to VCS checkout: - Long-term reproducible stable archival file format, instead of an interactive online protocol that lack stable reproducible stored-file equivalent. - No assumption about WebPKI or SSH TOFU server authentication. - Allows PGP/SSH/Sigsum/etc signatures to be applied to the tarball. - Smaller size: only includes necessary source code; no project history or other unrelated content that may be used as a xz-style payload mechanism. - Smaller toolchain requirement for unpack: compare dependency chain of 'git' with 'tar'. /Simon
signature.asc
Description: PGP signature
