On 12/3/2025 4:14 PM, Greg Troxel wrote:
I can cope, but I would ask if there is anybody else (packaging, not
people wanting to hack on fibers) that thinks not having a tarball is
ok.
Yes. (Has been a while since I did packaging stuff.)
Git checkouts tend to have less binaries. Unlike tarballs, where often
"configure" and "Makefile.in" binaries are added. Convenient for
build-from-source (if you use 'configure' without compiling it yourself,
it's not a full from source)! Convenient for proper bootstrapping (not
essential since you could automatically recognise these binaries and
remove them, though that didn't go anywhere).
And slightly reduces risk of malware (configure.ac much smaller than
configure, way easier to check for malware).
(Just because they are textual and readable, doesn't make them not
binaries. It's compiled, so it's a binary and not source. Or don't call
them binaries if you don't want to and call the process something
different than 'compilation', but that's just a terminology thing. It's
still not source.)
Well, ok, there should actually be tarball (or zip etc.). But they don't
have to contain (and preferably don't contain) "configure" and
"Makefile.in" (*). A long time in the past, where package managers were
kind of absent you couldn't just "[cmd] install autoconf automake",
those were important to include ... But you are adding something to a
package manager / distribution (and not a super new one) that does
compilation, so I'd expect autoconf and automake to be available?
(*) except for stuff like gcc, make, bash, ... where otherwise there
would be a loop in the absence of an elaborate bootstrapping process.
Best regards,
Amélie Devos
