Arch package

[jonhoo]

Took the liberty of creating an Arch Linux package for this: https://aur.archlinux.org/packages/topfew

Don't know if you want to list that somewhere as part of installation instructions — if not, feel free to close :)

[jonhoo]

(happy to hand over ownership of it if you'd prefer)

[timbray]

Why, thank you so much. I hate to admit it, but despite my decades of software I have never actually published this kind of command-line thing so I have no ideas what the issues are and what to watch out for. On top of which I normally live in Deb or Ubuntu. Does this mean that someone on an ordinary Arch box could type pacman -S topfew and it would just work?

I’m inclined to say “yes, thank you” and update the installation instructions, where by “update” I mean “create”. As for the ownership, given my Arch-ignorance I doubt I’d add value. Which leads to a question: Assuming you continue owning this, what do I do if/when I release 1.1.0 or even a hypothetical 2.0.0 to make sure this package gets updated? I cloned your repo and I see that it has a pkgver variable (and also that there are some go build options I need to educate myself about.

[jonhoo]

Happy to help! And I think you're not alone — packaging for distros I think is often seen as a dark art, even though it's often just bash all the way down. For example, all the Arch package is is this script (a "PKGBUILD" accompanied by a writing guide and a linter). This particular one is mostly a copy-paste from the Go package guidelines for Arch.

Arch has two sets of repositories, the official repositories and the Arch User Repository (AUR). In general, new packages are submitted to the latter (where anyone can submit packages), and eventually graduate into the official repositories if they see sufficient demand + maintain a high quality install script over time. pacman only installs directly from the official repositories, though a number of tools exist to wrap pacman such that it can also install from the AUR, and most Arch users have one of them installed. For those that don't, the way to install from the AUR is as follows:

git clone https://aur.archlinux.org/topfew.git
cd topfew
makepkg -i

Where makepkg is a tool provided by pacman for building packages from source using a PKGBUILD (the -i flag means "install after building"). It's what's ultimately used to build every Arch package.

In terms of owning an AUR package, the submission guidelines has a decent section on maintaining packages, which is quite short. I'd say the main two tasks for maintenance are to cut a new release of the package when there's a new upstream release and to monitor for comments on the package (you can enable email notifications). Cutting a new release is very straightforward:

1. change the pkgver line in the PKGBUILD
2. run updpkgsums to download the new release tarball and stick its shasum into the PKGBUILD
3. makepkg --printsrcinfo > .SRCINFO to update the package metadata
4. git commit && git push to release

I'm happy to just do that though — no need for you to get up to speed on a completely new ecosystem just to enable Arch folks to use the package more easily, especially when it's so little work on my part :) Can't guarantee I'll have the time in perpetuity, but for now 👍

As for what to do on your end on a release, I'd be happy to give you push rights to the package so that you can do the update process above proactively yourself, but otherwise just ping me when there's a release and I can do that quick ritual to bump the Arch package (I also already have notification for new topfew releases on GitHub).

[timbray]

That all makes sense. I'm writing an INSTALLING.md and will include the instructions there. For the foreseeable future, I'll notify you about any releases. As for commit rights, does aur.archlinux.org have a PR-like mechanism? Rather than pushing myself, in the short term I'd be happier preparing a PR for you to look at and once it seems like I have the details right, I'd be more confident about pushing.

Also, questions:

First, the tf-linux-x86.gz binary in https://github.com/timbray/topfew/releases should run OK on arch, right?

Next I'm interested in the GOFLAGS from your PKGBUILD:

-buildmode=pie -trimpath -ldflags=-linkmode=external -mod=readonly -modcacherw

I've looked them up and I think I understand what they do. Do you have opinions as to the value they add; should I consider adding them to the standard binary-build step of the release automation? I had (perhaps naively) assumed that the go build defaults would more or less do the right thing.

[timbray]

Oh wait, I just read https://wiki.archlinux.org/title/Go_package_guidelines and https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro - my conclusion is that there is no harm and potentially good benefits from copying those GOFLAGS. Do you agree?

[jonhoo]

As for commit rights, does aur.archlinux.org have a PR-like mechanism?

Sadly no. Official packages have a full-fledged GitLab instance, but the AUR is just git. Feel free to email me patches if you want to give it a try though (jon at the domain of https://thesquareplanet.com) :)

First, the tf-linux-x86.gz binary in https://github.com/timbray/topfew/releases should run OK on arch, right?

Yes, I don't see why not. The most common issue with pre-built binaries is if they're built with a newer glibc than the installation target, but that's unlikely to be the case with Arch given it's rolling release. The next most common is that the pre-built binary uses versions of system libraries that don't match what is available in the distro, but that shouldn't be the case here since the only dependency (I think) is glibc.

For go packages, builds are so fast that I'm not terribly concerned about building from source though. I think that's also generally the Arch preference to make patching, seeing what changed, matching system libraries, etc. easier. If the package becomes an official Arch package, the built package is also what is generally installed by users, so they don't pay the cost of building from source (unless they want to).

There is a preference in the Arch community to not rely on GitHub auto-created source tarballs since they aren't guaranteed to match the actual contents of the repository (or the sources used to build pre-built release artifacts), but that matters more for C projects that rely on autoconf than for things like Go projects.

[..] my conclusion is that there is no harm and potentially good benefits from copying those GOFLAGS. Do you agree?

I don't do a whole lot of Go any more these days, but the flags do seem pretty reasonable to me. I'm honestly not sure why they aren't used by go build by default, but 🤷 It could be that they make the resulting binary less portable perhaps, so depending on how important that is for you for the published binaries, that may change the calculus. I'd personally probably take the path of "make the binaries more secure by including the flags until someone complains".

[timbray]

Great, thanks. I’ll shoot you a diff when I do a release. Maybe it’ll be official some year.

…

On May 9, 2024 at 3:28:56 AM, Jon Gjengset ***@***.***> wrote: As for commit rights, does aur.archlinux.org have a PR-like mechanism? Sadly no. Official packages have a full-fledged GitLab instance, but the AUR is *just* git. Feel free to email me patches if you want to give it a try though (jon at the domain of https://thesquareplanet.com) :) First, the tf-linux-x86.gz <https://github.com/timbray/topfew/releases/download/v1.0.0/tf-linux-x86.gz> binary in https://github.com/timbray/topfew/releases should run OK on arch, right? Yes, I don't see why not. The most common issue with pre-built binaries is if they're built with a newer glibc than the installation target, but that's unlikely to be the case with Arch given it's rolling release. The next most common is that the pre-built binary uses versions of system libraries that don't match what is available in the distro, but that shouldn't be the case here since the only dependency (I think) is glibc. For go packages, builds are so fast that I'm not terribly concerned about building from source though. I think that's also *generally* the Arch preference to make patching, seeing what changed, matching system libraries, etc. easier. If the package becomes an official Arch package, the built package is also what is generally installed by users, so they don't pay the cost of building from source (unless they want to). There *is* a preference in the Arch community to not rely on GitHub auto-created source tarballs since they aren't guaranteed to match the actual contents of the repository (or the sources used to build pre-built release artifacts), but that matters more for C projects that rely on autoconf than for things like Go projects. [..] my conclusion is that there is no harm and potentially good benefits from copying those GOFLAGS. Do you agree? I don't do a whole lot of Go any more these days, but the flags do seem pretty reasonable to me. I'm honestly not sure why they aren't used by go build by default, but 🤷 It *could* be that they make the resulting binary less portable perhaps, so depending on how important that is for you for the published binaries, that may change the calculus. I'd personally probably take the path of "make the binaries more secure by including the flags until someone complains". — Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEJEYWZEFJ6LQNIWRHUSLZBNFWRAVCNFSM6AAAAABHHSXG6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBSGM4TMMZXGM> . You are receiving this because you commented.Message ID: ***@***.***>

[timbray]

Anyhow, closing this issue. Will be releasing 1.1.0 soon with an INSTALLING.md

Thanks for this work!

[timbray]

I recently released 2.0. It's a breaking change because Homebrew wouldn't take my binary name of "tf" because that's what everyone uses for Terraform, so it's just "topfew". No biggie.

[jonhoo]

Yep, I've already pulled in 2.0 into the Linux package, though did not change the binary name. Happy to do so, though (as discussed over email) the manpage should then probably be renamed first too.