Still, I'd give a +1 if Arch devs decide to make the chroot method the default.
Not quite sure what you mean by this. As I understand it, Arch packages are already built in a clean chroot. The Arch devs don't control whether people use the same method to build AUR/other packages for their own use or not. Or did you mean you'd like to see the wiki page recommend it as default?
]]>Still, I'd give a +1 if Arch devs decide to make the chroot method the default.
]]>Just to add another perspective...
For packages that don't require a ton of build-deps, or those that I build so frequently that I've kept those deps installed, I just makepkg in a certain folder and routinely (part of backup checklist) clean up orphans via pacman.
For one-off packages (testing upstream cherry-picks or commit reverts), or those that require a lengthy list of build-deps, I do the manual clean chroot build method. It's mighty easy - don't let that "dev" aspect sway you.
As the counter of times I've seen extra-x86_64-build mentioned in such discussions continues to increment I'll likely give that a go some near-future date!
]]>I think you might be getting a little too hung up on Scimmia's "which you should be".
FWIW I've never built an AUR package in a chroot. None of my computers have blown up... yet.
Ah, thanks to you both. I think I will keep it in mind for troubleshooting and not try to figure out a new workflow at the moment, at least. Trying to get my head around VPN is more than enough frustration for now!
]]>I think you might be getting a little too hung up on Scimmia's "which you should be".
Ah, ShouldLand ...
FWIW I've never built an AUR package in a chroot. None of my computers have blown up... yet.
]]>There is also the problem of wiki house keeping. The clean chroot article is in the dev namespace of the wiki and it's probably not entirely understandable for everyone. The tools have potentially confusing names. Unless that is somewhat cleaned up/streamlined, suggesting it to every single beginner might lead to exactly those support threads that suggesting a clean chroot tries to prevent in the first place.
I just use makepkg -i after running devtools.
Now I feel stupid.
]]>If this is correct - and I'm certainly not suggesting it isn't - then why doesn't the AUR page explain how to do this for an AUR package? Of even that it should be done? I realise it may seem straightforward to people answering this, but ... I followed the wiki. When the AUR changed, I followed the wiki again. But I was following the wrong bit of the wiki?
Edit: Apologies. I spent the weekend trying to connect to a VPN so I can access files I used to access using cadaver. And I achieved nothing. I shouldn't have asked this question when I'm entangled in dead non-CIFS ends and addresses I can't figure out.
]]>The devtools method fails for me every time I try it. Example:
Installing auracle-git from the AUR
...
(1/1) Arming ConditionNeedsUpdate...
Checking PKGBUILD
PKGBUILD (auracle-git) W: PKGBUILD uses internal makepkg 'msg2' subroutine
Checking auracle-git-r366.8739929-5-x86_64.pkg.tar.zst
auracle-git W: Dependency included and not needed ('libcurl.so')
==> Running checkpkg
error: target not found: auracle-git
==> WARNING: Skipped checkpkg due to missing repo packages
Then it just dropps me in the shell again. It works with makepkg.
]]>slithery wrote:Just because you aren't a dev doesn't mean that you can't use scripts such as extra-x86_64-build from the devtools package.
But is there a reason to? It means trying to knit together the AUR instructions with the developer instructions. That's a lot of complications if there's not a good reason to do it.
You don't have to 'knit together' anything. Just cd into the directory that contains the PKGBUILD and run extra-x86_64-build (or ccm c & ccm s) instead of makepkg.
slithery wrote:All make depends are only installed into the build system chroot and never on to the machine that you are installing to.
Is this a good reason to do it that way?
Yes. It provides an answer to the question you asked about not having to install makedepends onto your system.
https://wiki.archlinux.org/title/Develo … ean_chroot
https://github.com/graysky2/clean-chroot-manager
Yes, but I'd have to give the user sudo rights and I've been reluctant to do that.
If your user doesn't have sudo rights, remove sudo, then makepkg -s will use `su`. But in any case, you need to run pacman somehow, right? That requires some way of elevating rights.
]]>Ah, this doesn't add up. You still run makepkg as a regular user. With the -s flag it just runs the same pacman command (with sudo / su) that you would to install the dependencies, it just handles gathering that list of target packages for you.
Yes, but I'd have to give the user sudo rights and I've been reluctant to do that. I dare say that's paranoid or pointless or both, but that's why I've never used -s.
Just because you aren't a dev doesn't mean that you can't use scripts such as extra-x86_64-build from the devtools package.
But is there a reason to? It means trying to knit together the AUR instructions with the developer instructions. That's a lot of complications if there's not a good reason to do it.
All make depends are only installed into the build system chroot and never on to the machine that you are installing to.
Is this a good reason to do it that way?
Right now, I rely on the previous PKGBUILD when an AUR package is updated. I imagine this would be lost (or, at least, be more complicated) if building in a chroot.
I'm not suggesting the way I do it right now is ideal. I'm just trying to get a sense of why people are suggesting the different things they're suggesting (since Trilby seems not to be using clean chroots?).
]]>