Hello Sean, On Monday, 28 August 2023 23:52:28 CEST Sean Snell wrote: > Hello, I'd like to start testing my PKGBUILD work with devtools prior to > pushing my work to the AUR however I rely on packages based in the AUR for > dependencies and when I try to use *extra-x86_64-build* in the location of > the PKGBUILD it works for a bit but then fails because it can't resolve the > AUR-based dependency packages. That makes sense as it's replicating the > local *makepkg -s* process, which would also fail if I didn't have those > dependencies installed ahead of time. > > I normally accomplish this with yay > <https://aur.archlinux.org/packages/yay> then > build the PKGBUILD with *makepkg -s*. How do other AUR maintainers > traditionally resolve their AUR-based dependencies when working with > devtools? I'm not opposed to using yay with devtools if pulling in an AUR > wrapper is appropriate; I'd just like to avoid having to manually install a > bunch of dependencies by hand before I'm able to test if my PKGBUILD work > is sound. Thanks!
I personally use paru [1] with LocalRepo and Chroot enabled. In this way you get the benefits of makechrootpkg, and it also solves the AUR-based dependencies issue you mentioned. The only missing feature would be to pass custom flags to makechrootpkg if you want to perfectly emulate extra-x86_64-build. For example, paru will not run namcap on the package. But you can manually still do this because paru will save your package to your local repo. Cheers, Iyán [1]: https://github.com/morganamilo/paru
signature.asc
Description: This is a digitally signed message part.
