On 2025-02-26 21:53:50 (+0100), Jelle van der Waa wrote:
After all the recent RISC-V news I went ahead and checked out the existing effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of PKGBUILDs which require customization to be be able to build on RISC-V. A lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in prepare(), this re-generates `configure` to understand RISC-V.
Since these patches are simple enough and I don't see them harming Arch Linux, I would argue that we want these patches applied in our packages. Re-generating configure should not break, and if it does we should not accept the patch and get a bug filled upstream.
Yes, this is generally a good idea and usually works withouot issue. Exceptions can't easily be detected though as we currently expect base-devel to be installed and not autotools specifically. However, they usually include: - projects with ancient and custom autotools (looking at you ncurses 👀) - projects where `configure` is actually not autotools (looking at you qemu 👀)
Re-creating configure and thus not using the provided `configure` could arguably also be a good thing regarding supply chain security. And this also should help with other architecture ports.
That's also what RFC0046[1] is about in consequence. When not relying on custom source tarballs, autoreconf (or some custom bootstrap script like autogen.sh) usually must be run.
As a follow up we can discuss providing our own "/usr/share/config.site" and then ./configure --prefix=/usr would automatically configure localstatedir, libexecdir, etc.
That would also be great and I think should be developed and maintained by us in a dedicated project, together with the custom `arch-meson` and any future cmake presets[2]. Best, David [1] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/46 [2] https://gitlab.archlinux.org/archlinux/ideas/-/issues/15 -- https://sleepmap.de