Hi, Jack Hill <[email protected]> skribis:
> It seems a bigger problem is when the build method for the git > repository and release tarball are different. In many packages this is > because of the pre-generated autotools build system in the release > tarballs. Should we bootstrap the autotools build system even when > building from a release tarball? As I understand it, autotools has > historically been treated this way in part to allow building on > systems without the right version of autotools, but is that really a > problem in Guix? Why should it be treated differently than other > pre-generated artifacts which we rebuild? You’re pointing out a contradiction here. On one hand, we take advantage that Autotools-based programs require nothing but a POSIX shell and make to be built, unlike most other build systems, which greatly simplifies our dependency tree. On the other hand, we’re striving to build everything from source, and Autotools-generated files look like elephants in this room. Debian has been dismissing those files for a long time. Probably we should aim towards not using pre-built Autotools generated files and, by extension, probably not using pre-built tarballs when VCS checkouts are available. It’s kinda happening on leaf packages, often upstream developers people don’t bother running “make dist”. It’ll take some time before tarballs disappear and needs some thought in particular from a bootstrapping standpoint. > Another improvement we could make here is improving the message about > Software Heritage in guix lint. Most of the other messages it emits > are things that the author of a package should consider improving. If > the Software Heritage message is less actionable, let's make that > clearer so that people don't think there is a problem with their > package definition. What message would you suggest? Thanks, Ludo’.
