Arch Linux User Repository

Important: This package sets its version dynamically. You'll get the newest zig bins from ziglang.org each time you run makepkg, and the package version will update.

Please flag this package as out-of-date only if something in the build process is broken. Thanks

@vitaliikuzhdin yes, i'm aware. that's why the unstable and stable zig packages are in conflict.

anyway, i've deleted zig from provides, but added a zig-unstable that could be shared with zig-git.

@ckafi, if zls-git depended on zig-git, it would work just fine since zig-git installs its binary to /usr/bin/zig.

@vitaliikuzhdin i'll just change the pkgver without bumping epoch. there shouldn't be any problems with that.

you're right that zls-git should depend on some form of zig-git or zig-master, but afaik even at runtime it depends on the zig executable being a non-stable version. so you can't have stable zig and unstable zls working together or vice versa.

if we don't care about zls-git i could drop the provides. the PKGBUILD hasn't been updated in over 2 years so i'm not sure if it's still maintained.

@ckafi, not sure if adding the g brings any real benefit, so I’d rather stick with what the upstream maintainer has chosen. It still uses git describe under the hood. The only way to avoid adding epoch=1 is to wait until the master branch moves to 0.17.0. You could do that, it shouldn’t take long now that stable Zig is at 0.15.2 and moving toward 0.16.0. Or you could just add the epoch, like zig-dev-bin did; I don’t see any issue with that. Speaking of which, you should probably submit a merge/delete request for that one too.

I haven’t looked deeply into the ZLS documentation, but wouldn’t it depend on zig-git rather than zig-master? It seems to me that zls-master (and zls-master-bin) would depend on zig-master, and I’ve already uploaded both of those. In any case, those two ZLS packages can serve as references for versioned implementations.

@vitaliikuzhdin

• added loong64.
• the pkgver() descends from the zig-nightly-bin PKGBUILD. i think the idea of the original author was to make it behave more like git describe, which does add a 'g' in front of the commit hash. i'm fine with changing it. do you know of a way to sneak it in without bumping epoch? also thanks for pointing out vercmp, i didn't knew that existed.
• i agree that not providing zig and installing into /opt would be cleaner, but currently both building and using zls-git requires that the canonical zig is the master release (or at least close to). while one could get around that with a .local/bin symlink or similar, i personally find it the most convenient to have the system version to be master. if you occasionally need to use a tagged version, just extract that tarball somewhere, no need to install it.

@ckafi, ah, it seems I forgot about longarch64 -> loong64. See this RFC for a (mostly) up-to-date list of valid $CARCH values: https://rfc.archlinux.page/0032-arch-linux-ports/#motivation

Speaking of anyzig, if we follow the same logic, it could also replace this package. In fact, anyzig master *command* checks the newest version on every invocation, providing the absolute latest release. However, the reasons for having a system-wide package with proper provisions and version declarations are obvious, hence why this and other versioned packages exist. There are plenty of other compilers with outdated versioned packages, both in the official repositories and on the AUR.

The only reason I've been messing with symlinks is to maintain a more canonical folder structure. The zig executable has an interesting way of finding its libdir; see this section: https://github.com/ziglang/zig?tab=readme-ov-file#installation

Technically, we can dump everything into /usr/lib/$pkgname, but then the libdir would be /usr/lib/$pkgname/lib instead of just /usr/lib/$pkgname. I don't know if that matters. If not, there’s no need to "mess" with symlinks (just create two of them) and you can just change the installation directory from /usr/lib/zig to /usr/lib/$pkgname.

The reason for removing the zig provision and versioning the installation is that this package follows a different branch of the project. Specifically, it will always be one version ahead, currently 0.16.* vs 0.15.* in the stable branch. When you claim to provide zig, it implies you’re providing the stable branch, so everything should build against it just fine, but it doesn’t. Take versioned packages as an example (though those usually ship past versions rather than future ones): they’re almost never allowed to claim to provide the main package from the official repo, as that could break setups or workflows. I’m not saying this package will be deleted, but following the standards would be cleaner. Also, not being able to have both the stable and master branches of Zig installed is annoying. When developing for master Zig or developing Zig itself you almost always need to compare behaviors. Reinstalling packages every few minutes gets very annoying.

As for versioning, the current scheme is slightly incorrect. It fails in an edge case when the stable Zig matches the master Zig:

$ vercmp 1 2
-1
$ vercmp 2 1
1
$ vercmp 0.16.0_dev.238.g580b6d1fa 0.16.0
1

As you can see, this will not be considered a new version. The correct way to handle this is to remove the underscore altogether:

$ vercmp 0.16.0dev.238.g580b6d1fa 0.16.0
-1

I also don’t see a point in other "cleanups," like replacing the plus sign or adding an extra g. That only adds confusion, creates differences upstream is unlikely to appreciate, and brings no real improvement. This is especially true since, for pacman, the dot and plus symbol are equivalent:

$ vercmp 1.1 1+1
0

You might want to check out my approach in zig-mach-bin, which shows a clean and simple way to handle versioning.

@vitaliikuzhdin i've added architecture mapping similar to yours. i don't know what valid values CARCH can have, so let me know if anything needs changing.

regarding not conflicting with extra: if someone needs multiple versions of the compiler, i'd recommend anyzig[1], rather than futzing around with symlinks.

i think it's fair to delete zls-nightly-bin since it looks unmaintained. doubly so because i just put in a deletion request for zig-nightly-bin.

[1] https://github.com/marler8997/anyzig

@ckafi, thanks for adding the zig-master provides. I've just updated zls-master-bin to depend on it. Speaking of which, could you please review the architecture mapping logic it uses and implement something similar here? It might not be entirely accurate, but the current logic does not support architectures named differently by Zig and provides a non-existent arm triple.

Also, have you considered making this package non-conflicting with the zig package from extra? I think it would be very useful to combine both the stable release and the master one. Implementing this is very easy, you can take a look at the zig0.* packages.

Lastly, considering the naming convention used upstream, would I be correct in assuming zls-nightly-bin should be deleted?

Thanks for maintaining!

@Sashko: thanks, patch applied

I propose this patch to support ARM and RISC-V. It worked for me on aarch64 Linux laptop.

diff --git a/PKGBUILD b/PKGBUILD
index 3f4ec78..ea081c4 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -4,7 +4,7 @@ pkgname=zig-master-bin
 pkgver=0.15.0_dev.1228.g6dbcc3bd5
 pkgrel=1
 pkgdesc="A general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software (master release)"
-arch=('x86_64')
+arch=('x86_64' 'arm' 'aarch64' 'riscv64')
 url="https://ziglang.org/"
 license=('MIT')
 provides=('zig' 'zig-master')
@@ -14,8 +14,8 @@ options=('!strip')

 _index_json=$(curl -s "${url}/download/index.json")
 _master_version=$(echo "$_index_json" | jq -r '.master.version')
-_tarball_url=$(echo "$_index_json" | jq -r ".master.\"x86_64-linux\".tarball")
-_tarball_sha256=$(echo "$_index_json" | jq -r ".master.\"x86_64-linux\".shasum")
+_tarball_url=$(echo "$_index_json" | jq -r ".master.\"${CARCH}-linux\".tarball")
+_tarball_sha256=$(echo "$_index_json" | jq -r ".master.\"${CARCH}-linux\".shasum")
 _tarball=$(basename $_tarball_url)

 pkgver() {