Don't leave build stuff in my home dir, please about pkgbuilds

[sudoforge]

To wit, there is no expectation that running makepkg has no side effects. The typical way to ensure a build is "sandboxed" is to build in a chroot; this is made possible by using systemd-nspawn via makechrootpkg (or if you use a sane helper like aurutils)

That said, I understand the desire to have builds "sandboxed" and would prefer this myself (although I typically use -bin packages which avoids this altogether), and can agree that this could be useful behavior for some folks. Thanks for the suggestion!

[sudoforge]

@magthe I've added a patch setting GOPATH to $srcdir/.go. This accomplishes the desired outcome, which is to not have files left over in your user's $GOPATH (by default, ~/go) when invoking makepkg directly or using aur helpers like yay.

I did not add the go clean command you suggested as I firmly believe it is the responsibility of the user (if using makepkg) or tool (e.g. yay) to clean up after builds, if that's the desired behavior. With makepkg, you can do this by using the --clean or --cleanbuild options. From man makepkg:

OPTIONS
       -c, --clean
           Clean up leftover work files and directories after a successful build.

       -C, --cleanbuild
           Remove the $srcdir before building the package.

Another suggestion is to poke your AUR tool author(s) to build packages in a sandbox (using makechrootpkg, systemd-nspawn, or whatever they'd prefer), and clean up that sandbox after building the package. Far too many AUR helpers fail to implement this sort of behavior, which leads to weird issues for users. The poor architecture of many AUR helpers is exactly why they are not recommended for use.

One tool I use is aurutils, which simplifies the management of a Pacman-compatible repository. I use aurutils both manually and in an automated manner on a small server I have that builds packages for me on a schedule. From my workstation, I simply add the repository and install/remove/update packages using pacman.

[sudoforge]

I should also note that I'm conflicted about this patch. On the one hand, it helps users like yourself who are running makepkg directly (or using a tool which does) and assuming that it will be sandboxed; on the other, it prevents sharing cached objects across multiple invocations of go build (and even across package boundaries, libaries, projects), which is actually a benefit if you are running makepkg directly (or using a tool which does) on built-from-go-source packages, or writing Go packages or binaries in some other capacity on your system.

I offer no guarantees that this patch will live in the codebase forever.

[magthe]

I did not add the go clean command you suggested as I firmly believe it is the responsibility of the user (if using makepkg) or tool (e.g. yay) to clean up after builds, if that's the desired behavior. With makepkg, you can do this by using the --clean or --cleanbuild options.

I'm guessing you didn't try this out. Since the creators of Go decided to give all dependencies 444 as permission they've made makepkg --clean end with many, many lines like this

rm: cannot remove '<build location>/terragrunt/src/.go/pkg/mod/go.mozilla.org/sops/[email protected]/LICENSE': Permission denied

and a bunch of leftover files and directories are left in place.

I offer no guarantees that this patch will live in the codebase forever.

That is of course entirely up to you. I'm grateful you made this change at least.

[sudoforge]

I'm guessing you didn't try this out. Since the creators of Go decided to give all dependencies 444 as permission they've made makepkg --clean end with many, many lines like this

rm: cannot remove '<build location>/terragrunt/src/.go/pkg/mod/go.mozilla.org/sops/[email protected]/LICENSE': Permission denied

and a bunch of leftover files and directories are left in place.

You're correct, I only tested rebuilding with --cleanbuild, which doesn't have this same problem.

Hm.

I suppose I can add the go clean call, as modules would really only be re-fetched if the user A) has deleted the package file, or B) is passing -f to makepkg, in which case the argument could be made that re-fetching the modules is fine.

--

I'd stress, again, that this is abnormal and out-of-band for a PKGBUILD -- it's the responsibility of the user to build the package in a container if that's the behavior they want. This is why makechrootpkg, makepkg --clean, and makepkg --cleanbuild exist (I can recognize that --clean doesn't work in the case of Go modules).

Since you're using yay, it's the responsibility of that tool to provide this behavior. A quick search shows Jguer/yay#1213, which I'd recommend you throw your vote behind, so you can yay --chroot to your heart's content (or whatever the flag ends up being).

Or look into aurutils and manage AUR packages in a different, perhaps better way.

[sudoforge]

@magthe More to the point, can I ask why you want to avoid using your user's $GOPATH when building AUR packages? In theory, it is only beneficial to you, as your builds of this package (and other packages which build Go binaries) may benefit from any modules which you already have cached.

The only concern I can see is related to disk space usage. Am I missing something else?

[magthe]

1. I don't program in Go at all, so I don't have $GOPATH set, and it pollutes my $HOME by default.
2. I have a few other tools written in Go built and installed from AUR and they don't leave intermediate build artefacts outside of the buid folder, so the behaviour of your package surprised me.
3. I really think that all packages on AUR should build properly with makepkg.

[sudoforge]

I don't program in Go at all, so I don't have $GOPATH set, and it pollutes my $HOME by default.

That makes sense, as $GOPATH defaults to $HOME/go (annoyingly, the module cache should IMO be placed in $HOME/.cache/go but I digress)

I have a few other tools written in Go built and installed from AUR and they don't leave intermediate build artefacts outside of the buid folder, so the behaviour of your package surprised me.

Can you provide an example of a few of these packages? Are they by reputable maintainers? I would guess that they are running go clean after building, in the package() function or a post-installation script. This has the downside that I want to avoid of preventing re-using the module cache between builds which are not cleaned.

I really think that all packages on AUR should build properly with makepkg.

This package does, and has always, built properly with makepkg. The new behavior of printing warnings out when using the --clean flag is caused by the movement of the $GOPATH to a path within $srcdir, which was done to address the concern you brought up in your first issue comment. The initial issue you posted about did not and does not prevent this package from building successfully (in fact, it re-used the module cache when possible, which was the intended behavior).

[sudoforge]

@magthe I believe I've found a nice middle ground for the two goals:

• Allow deletion of the module cache so commands like makepkg --clean and other processes (e.g. rm -rf, git clean -fdx, etc) can delete the workspace as expected
• Allow rebuilds not cleaning the workspace to benefit from re-using the module cache

Check out 660e77e for more information.

[sudoforge]

Actually, bd6ade1 is a cleaner approach that accomplishes the same goals. TIL.

[magthe]

Nice!