On 2023-01-17 14:40, Robin Candau wrote:
Since the related packages I currently maintain in the AUR does not depend on a specific toolchain to be built (as seen with upstream), is it safe for me to drop the toolchain definition in the PKGBUILD or you're suggesting putting it back to "stable" anyway?
My suggestion would be to *always* include the toolchain selection and choose stable for PKGBUILDs in the AUR even if the project nominally works with nightly. This goes along with also using the other arguments for freezing the dependencies against the upstream lockfile rather than dynamically building with whatever comes down the pipeline at the time of build.
This will be less brittle (even if it works at the moment you test it with nightly and dynamic dependency updates it might not work a month later for some random user that gets an updated dependency or a new restriction in the compiler). Also it will be more reproducible. Reproducible builds are not a requirement or even stated goal for AUR packages like they are for repository packages, but they are still a general purpose good. Your package is reproducible when you can build it and I can build it and we both come up with bit-for-bit the same binary results. Arch Linux has tooling for verifying built packages are reproducible or not that takes into account the version of dependencies being used. The data about which version of rust and cargo were used are logged in your package at the time you build it and can be used to recreate a test environment exactly like yours. If you allow packages to be built with rustup and unlocked dependencies they will not be reproducible. If you explicitly set the tooling to use the stable versioned packages at build time they will be. In almost all cases if you follow the Rust package guidelines in the wiki you'll get a reproducible package out of the deal.
