Arch Linux User Repository

Thanks for the detailed feedback @alerque, and I apologize for the frustration this has caused.

You're right that the recent releases have had packaging issues that should have been caught before pushing to AUR. I've taken steps to prevent this going forward:

Immediate fixes (PR #404, merging today):

• CFLAGS+=' -ffat-lto-objects' for ring crate LTO compatibility

• Fixed host-tuple to use actual host triple from rustc

CI gate added:

I've added an AUR workflow that tests the PKGBUILD in an Arch Linux Docker container before any release PR can merge. It runs makepkg, validates with namcap, and tests installation. This means broken packages can no longer reach AUR.

Regarding your Feb 15 feedback:

• depends=(glibc libgcc) - will update
• Removing rust version pinning from makedepends - will update
• Adding prepare() with cargo fetch --locked --target "$(rustc -vV | sed -n 's/host: //p')" - will update
• Moving conflicts/provides to the -bean-compat split package only - will update

I'll push these PKGBUILD improvements once the current fix is verified.

I understand the trust has been damaged. The CI gate should help. You can see it at .github/workflows/aur.yml in the repo. Future releases will be tested against Arch before they reach AUR.

Also to be clear, the regressions are not caused by "the bot", yes some regressions were reintroduced but 'the bot' is just the CI (the CI has no LLM built in), my changes are made seperately and committed. I fixed the issues you addressed, and I was hoping those changes would persist when moving the process to CI, but they did not. That's my oversight, but also it's my first time setting up CI for AUR, and I noticed there's absolutely zero guidance or official actions for this, which is intentional by the Arch commmunity. It is not surprising that some garbage gets committed when CI scripts are being developed/tested. Apparently some effort is being made to rectify this in https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/63 for official packages, but it's hard to parse exactly what they're talking about.

WARNING: This upstream is just vibe coding stuff and letting an LLM throw spagetti at the wall and see what sticks. I gave them a whole bunch of specifics to fix, and most of them got implemented... but now the bot is busy undoing those fixes and adding new breakages. The last three commits as of this commit time are COMPLETELY bogus.

A few comments of packaging (from an Arch Linux package maintainer):

• The depends needs to be fixed with the actual packages it depends on, the gcc-libs package is deprecated and split up into more specific packages. Having compiled this and actually checked, what you need is depends=(glibc libgcc)
• Remove the minimum version pinning from the rust build dependency. The Arch package is past that point anyway.
• In fact you can remove rust entirely since it is just an alias anyway, makedepends=(cargo) is correct in this case.
• Drop the provides=(rledger). I know that is a binary in the package, but that is not what the provides= declaration is for at all. No other packages should depend on it by it's binary name, they will always use the actual package (base) name.
• Speaking of base names, also drop the conflicts= declaration. It is appropriate for the rustledger-bin package to provides=(rustledger) and conflicts=(rustledger), but not the other way around. Check the packaging guidelines but the resolved takes care of the other direction and these should only be used in variant packages (bin, vcs, etc.) not the canonical base package.
• The use of $srcdir is pointless, the build spec declares the functions will always be run in $srcdir anyway.
• a prepare(){} function that preloads the Cargo cache with just the packages needed for the target arch (cargo fetch --locked --target host-tuple) will save quite a bit of downloads and enable offline builds. Then change --locked to --frozen in the other cargo invocations so they don't check the network.
• Do the "beancount compatibility" binaries need to invoke a conflicts=(beancount) and/or provides=(beancount)? If they are drop in replacements for that package they should. But...
• If they are drop in replacements I would actually make those a split package and/or actually package them behind a prefix so people can install both beancount and rustledger for local testing, comparisons, etc.