Controversial flamebait of the day: A signed, annotated git tag is not a replacement for a release tarball.
Mike Linksvayer, Evan Prodromou, Christopher Allan Webber, jrobb and 2 others likes this.
Claes Wallin (韋嘉誠), lnxwalt@microca.st, lnxwalt@microca.st shared this.
Show all 7 replies
Reproducible git-archive might be an interesting thing to have. Maybe using nar (https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-archive.html) instead of tar.gz would be enough.
I never tried to avoid making tarballs, but I can make a wild guess there is a way to use a git hook that can generate the tarball for you once you push a new tag. Or some other automation. So even lazy/busy people can create tarballs reasonably quickly.
Personally, another motivation I have for tarballs is visibility. My git repos are self-hosted on my humble home server, but tarballs go to Hackage (I wanted to self-host in addition and make torrents of them, but so far it feels like an overkill so I just rely on Hackage).
Done with the push-my-life-story-into-a-comment thing :)
@fr33domlover - funny you'd mention it, i actually wrote a perl script to do just that (tarballs from git tag, with checksums):
https://redmine.koumbit.net/projects/git-hooks/repository/revisions/master/entry/archive-tag
https://redmine.koumbit.net/projects/git-hooks/repository/revisions/master/entry/archive-tag
If you can't always reproduce the same identical tarball from it, but you can reproduce the same verifable identical set of extracted files (I'm not sure you can, and in that case my whole argoument falls), is it still a problem?
It is going to be an hassle because our tools to verify things are assuming that there is a tarball, but that's a problem with our tools, not with the practice itself.
It is going to be an hassle because our tools to verify things are assuming that there is a tarball, but that's a problem with our tools, not with the practice itself.