3 ms·

The language+compiler are on 0.x so packaging it in long term support distros can be more problematic than helpful at this point (source that compiled a year ag

The language+compiler are on 0.x so packaging it in long term support distros can be more problematic than helpful at this point (source that compiled a year ago is likely broken now and vice versa). Once it has reached 1.x then it won't be much to get it prepackaged everywhere. Until that point it doesn't really make sense to pull it from the repos of distros that are packaging it right now anyways. E.g. it's packaged on Fedora but you most likely don't actually want to rely on that package for the moment.

TZubiri 2y ago
That would be a good reason. The thing is that it is present in many distributions. https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Packa... Perhaps the foundational distros are stricter.
- mook 2y ago
  That list says it's already in Fedora and openSUSE. The fact that they both have older versions is actually good, since that just means they've been packaging it for a while. Once that list no longer marks outdated versions as red is when zig would have been ready for the long-term supported distributions.
- zamadatix 2y ago
  Whether some distributions have jumped the gun or not it remains a good reason. No harm for the lot of ones in that list that are more delivery mechanisms or development versions themselves though. For the ones that are green they tend to be development versions (e.g. Alpine Edge, ALT Sisyphus, LiGurOS develop), rolling releases where there aren't necessarily those kind of package stability/interop guarantees in the first place (e.g. Arch, Manjaro, OpenSuse Tumbleweed), or not actually distros at all just alternative download mechanisms (e.g. Chocolatey, Chromebrew, Homebrew, Scoop). There are very few (such as Fedora 40) that just happen to be "broken clock" status for the moment because they are very fresh spins. For the ones that are red, they are the examples of why you don't want to rely on the built in package at the moment. Even for the ones that are green "for the moment" (such as the Fedora 40 example) it's often still considered better to use the latest "master" copy of zig (depending what you're doing with it) than the last milestone release even then.
foresto 2y ago
It doesn't have to be problematic. For example, PipeWire in Debian Stable is at 0.3.65 and probably won't get major updates until the next Debian release. However, that's only part of the picture: Its early presence in Debian has paved the way for updates via the Backports suite, which is available to Stable users with a flick of a switch. With Backports enabled, Debian Stable has access to PipeWire 1.2.4, released upstream less than two weeks ago. This could be done for Zig as well. (Assuming Zig meets the Debian Free Software Guidelines. I think its recent move to a WASM blob for bootstrapping might complicate inclusion in Debian.) https://backports.debian.org/ https://backports.debian.org/
- rc00 2y ago
  > This could be done for Zig as well. What's more, there is precedent with regards to Debian: Go is backported to Stable via the golang metapackage. The main package for Zig can follow the same structure and also be a metapackage with versioned dependencies. > I think its recent move to a WASM blob for bootstrapping might complicate inclusion in Debian. As I understand, it would mean that Zig ends up in the non-free component rather than main or contrib.
- zamadatix 2y ago
  > For example, PipeWire in Debian Stable is at 0.3.65 Pipewire did/does not follow the strict semver versioning so you can't compare the two because the versions both start with "0": - Pipewire had offered ~3 years of API and ABI compatibility on what it called "0.3.x", zig intentionally plans to break compatibility multiple times a year as it increments 0.x. - Pipewire already planned to keep API/ABI compatibility between 0.x and 1.x, zig explicitly does not - they label the releases 0.x to signify these will break by 1.x - Pipewire called 0.3.x stable for use but a rapid development version. zig is also under rapid development but they say they opposite in regards to stability guarantees. I.e. the issue is more than "how do you get a newer version on stable Debian?" and more "it's an explicitly unstable package with no version compatibility guarantees, distros don't like packaging that in their stable repositories". The easy answer to "be prepared" more or less is keep it in the dev repositories, like Alpine does, where there is no guarantee of stability or interoperability on updates. When zig declares itself stable (which, in its versioning scheme, will be 1.0) then it can just be added to stable without much work.

TZubiri 2y ago

That would be a good reason. The thing is that it is present in many distributions. https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Package-Manager https://github.com/ziglang/zig/wiki/Install-Zig-from-a-Packa... Perhaps the foundational distros are stricter.

mook 2y ago
That list says it's already in Fedora and openSUSE. The fact that they both have older versions is actually good, since that just means they've been packaging it for a while. Once that list no longer marks outdated versions as red is when zig would have been ready for the long-term supported distributions.
zamadatix 2y ago
Whether some distributions have jumped the gun or not it remains a good reason. No harm for the lot of ones in that list that are more delivery mechanisms or development versions themselves though. For the ones that are green they tend to be development versions (e.g. Alpine Edge, ALT Sisyphus, LiGurOS develop), rolling releases where there aren't necessarily those kind of package stability/interop guarantees in the first place (e.g. Arch, Manjaro, OpenSuse Tumbleweed), or not actually distros at all just alternative download mechanisms (e.g. Chocolatey, Chromebrew, Homebrew, Scoop). There are very few (such as Fedora 40) that just happen to be "broken clock" status for the moment because they are very fresh spins. For the ones that are red, they are the examples of why you don't want to rely on the built in package at the moment. Even for the ones that are green "for the moment" (such as the Fedora 40 example) it's often still considered better to use the latest "master" copy of zig (depending what you're doing with it) than the last milestone release even then.

foresto 2y ago

It doesn't have to be problematic. For example, PipeWire in Debian Stable is at 0.3.65 and probably won't get major updates until the next Debian release. However, that's only part of the picture: Its early presence in Debian has paved the way for updates via the Backports suite, which is available to Stable users with a flick of a switch. With Backports enabled, Debian Stable has access to PipeWire 1.2.4, released upstream less than two weeks ago. This could be done for Zig as well. (Assuming Zig meets the Debian Free Software Guidelines. I think its recent move to a WASM blob for bootstrapping might complicate inclusion in Debian.) https://backports.debian.org/ https://backports.debian.org/

rc00 2y ago
> This could be done for Zig as well. What's more, there is precedent with regards to Debian: Go is backported to Stable via the golang metapackage. The main package for Zig can follow the same structure and also be a metapackage with versioned dependencies. > I think its recent move to a WASM blob for bootstrapping might complicate inclusion in Debian. As I understand, it would mean that Zig ends up in the non-free component rather than main or contrib.
zamadatix 2y ago
> For example, PipeWire in Debian Stable is at 0.3.65 Pipewire did/does not follow the strict semver versioning so you can't compare the two because the versions both start with "0": - Pipewire had offered ~3 years of API and ABI compatibility on what it called "0.3.x", zig intentionally plans to break compatibility multiple times a year as it increments 0.x. - Pipewire already planned to keep API/ABI compatibility between 0.x and 1.x, zig explicitly does not - they label the releases 0.x to signify these will break by 1.x - Pipewire called 0.3.x stable for use but a rapid development version. zig is also under rapid development but they say they opposite in regards to stability guarantees. I.e. the issue is more than "how do you get a newer version on stable Debian?" and more "it's an explicitly unstable package with no version compatibility guarantees, distros don't like packaging that in their stable repositories". The easy answer to "be prepared" more or less is keep it in the dev repositories, like Alpine does, where there is no guarantee of stability or interoperability on updates. When zig declares itself stable (which, in its versioning scheme, will be 1.0) then it can just be added to stable without much work.