Rpm source releases have always been something that one needs to *build*. This
antipattern was the norm in autotools world that we no longer need with cmake,
but due to the autotools history, we traditionally bundled pre-built
documentation in the source releases because, why not. Shipping unreproducible
content in your source tarballs is an ill-fitting concept in today's world.
We want our source releases to be bit per bit identical to what you get
straight out of git, with zero build steps to generate content, defined by a
git tag. We still want a stable archive of that content generated and hosted on
rpm.org because, GH archive creation could change any day and render checksums
unverifiable. That archive should be generated in a "hermetic" environment
rather than a developers workstation. But that "canonical tarball" is just a
convenience really, the contents are trivially diffable to match 100%,
something that our traditional tarballs do not pass at all.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3565
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/3...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
