yay double-checks architecture, differently

[drws]

Affected Version

yay v12.0.5 - libalpm v13.0.2

Describe the bug

When an AUR package doesn't include the architecture it is being built on, Yay fails before the Proceed with install? dialog if the architecture is not added to PKGBUILD. If the PKGBUILD is edited to include the architecture in question, Yay will check again a bit differently after the Proceed with install? dialog and will ask The following packages are not compatible with your architecture: ... Try to build them anyway? - even though the architecture is in the PKGBUILD at that time.

These two-step and differently-behaving architecture checks should be simplified into one clear step if possible.

Reproduction Steps

1. Try to install a package that doesn't include your architecture
2. If the architecture is not added when offered, Yay will fail soon
3. If the architecture is added, Yay will proceed to Proceed with install?
4. Further down Yay checks the arch again - possibly wrongly since it will spawn another dialog: The following packages are not compatible with your architecture: ... Try to build them anyway?

Expected behavior

The architecture is checked once, after PKGBUILD edit offer and probably before the Proceed with install?. If the architecture doesn't match, spawn a warning and offer to skip the package or edit the PKGBUILD. Optionally an auto-edit option to automatically add the current architecture to the PKGBUILD could be offered as well.

[Jguer]

Hey @drws , I'm sure the behavior can be improved but the PKGBUILD edits are not read back into yay at this time. PKGBUILD parsing would need to be implemented as a forestep

[AladW]

PKGBUILD parsing will always be broken and adds a lot of complexity. If you really want to include user edits in the build process, run makepkg --printsrcinfo to regenerate .SRCINFO.

Of course the question is why OP didn't use -A in the first place.

[Jguer]

that's for sure, PKGBUILD parsing = regenerating .SRCINFO

[drws]

Passing -A to makepkg would also solve this particular problem. But a .SRCINFO regeneration would also come in handy in certain situations. Does Yay offer any option to include makepkg --printsrcinfo > .SRCINFO at a relevant time in a transaction?

There are still a few issues remaining that weren't discussed yet, namely that Yay checks for architecture twice and differently at that. Also, it could provide an additional option in the architecture-check dialog to be able to override the check (add -A to makepkg flags). Depending on outcome of this issue I can open a separate feature request if needed.