On Mon, Mar 31, 2025 at 12:56 PM Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > > tl;dr: change the Packaging Guidelines to recommend the raw "git > archive" or equivalent over the upstream tarball produced using > "make dist". > > This is inspired by the discussion in "Reproducible Builds" mailing list, > in particular [1]. > > Background: upstreams use version control for their projects, but in > packaging we use a "tarball". Nowadays, this tarball is often the output > of "git archive". But it is also common for upstream to use "make dist" > (in case of autoconf) or 'python setup.py sdist' (python), etc. > In particular, when we download from github/gitlab/…, the archive is > often autogenerated by the forge upon request, equivalent to 'git archive'. > > In general, those "upstream tarballs" include the results of some > local processing, for example translating a configure.ac source into a > configure script, using local autoconf macros. Those preprocessed > scripts can become outdated, and in fact we often run 'autoreconf' in > %build to "refresh". In the "xz debacle", an upstream tarball was used > to smuggle rogue payload that wasn't checked into git. Finally, those > "upstream tarballs" are generally not reproducible because they depend > on the build environment. So there are good reasons to start with the > "raw" tarball and build everything from that. > > Our packaging guidelines don't say much about which tarball to use. > I propose to make two changes: > 1. Say that "raw" tarballs SHOULD be used, rather than the preprocessed type, > when both are available from upstream, and there isn't a particular > reason to use the latter. > 2. Update > https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_revision_control > from svn to git and just use an link to a autogenerated github tarball. > > This is only "SHOULD", because sometimes the git tarball is too large > or has other deficiencies. Another reason is that the "upstream > tarball" may be signed, and that'd be preferred to the unsigned "raw" > archive. But those should be rare exceptions. > > There is also a whole category of projects like Rust, Pypi, and maven, > where we download the tarball from a language distribution website, > not from upstream directly. I'm NOT proposing that we stop using > those. Instead, later on, I would add the requirement that those > bundles must build reproducibly from the git checkout. But I'm leaving > this out of the current proposal for simplicity. > > [1] > https://lists.reproducible-builds.org/pipermail/rb-general/2025-March/003694.html
Just one question: how would you make those git forges output stable archives? GitHub itself explicitly says they won't and you shouldn't do that [2]. In line with your quest to reinvent NixOS, you might be interested in how it's solved there: fetchFromGitHub and friends unpack the tarball first. [2] https://github.blog/open-source/git/update-on-the-future-stability-of-source-code-archives-and-hashes -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
