if I remember right, I think Debian wants additions to apt to link libraries dynamically if those libraries are part of apt (or something like that)
if that's right, we might want to look into having the build be configurable to either statically or dynamically link libc, llvm, and lld
since dynamically is what apt might want
and of course anyone using Debian, Ubuntu, etc would want to do apt-get install roc
, so it seems reasonable to think about that use case in advance :big_smile:
Richard Feldman said:
if I remember right, I think Debian wants additions to apt to link libraries dynamically if those libraries are part of apt (or something like that)
Yes:
Some software packages include in their distribution convenience copies of code from other software packages, generally so that users compiling from source don’t have to download multiple packages. Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way. 16 If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible. 17
From https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
Richard Feldman said:
if that's right, we might want to look into having the build be configurable to either statically or dynamically link libc, llvm, and lld
I'll add this to my TODO's :)
dynamically link llvm
llvm doesn't actually support this (at least not officially, I guess it could be tried though).
Warning: LLVM-libc is not yet ABI stable; currently only static linking is supported
huh, TIL!
well that certainly simplifies things haha
although I think llvm may have more dependencies than just libc, if I remember right
possibly z3?
https://llvm.org/docs/GettingStarted.html#software
also for reference, zig itself recently landed in apt: https://ftp-master.debian.org/new/zig0.13_0.13.0+dfsg-1.html
and it appears that the name roc
is available :grinning_face_with_smiling_eyes:
Beating the Rocq name confusion allegations, one package at a time
Really not worried about that, as an aside
also available on nixpkgs
Soooo maybe we should try to reserve those ASAP?
I don't think reserving them is really a thing
we talked about it years ago
At least for nixpkgs, I'm sure we could put out a v0.0.1 dummy. I think squatting would be okay here. We could even do it for our v0.0.0-alpha1
Other package managers, I'm not sure
I understand not wanting to set the expectation that we're making releases
But I think it's worse for us to lose roc
I'm sure the odds of that happening are really low
But, you never know
Richard Feldman said:
also for reference, zig itself recently landed in apt: https://ftp-master.debian.org/new/zig0.13_0.13.0+dfsg-1.html
I wonder why it doesn't appear in Debian's package search or on Zig's installation guide page.
I think it's been newly added but hasn't made it into a stable distro release yet
Kinda surprising it isn't in sid (unstable) yet if it was merged a month ago
maybe it hasn't been approved by the ftp masters yet
I'm going to try to get roc on nixpkgs
What should our brief description be on nixpkgs for roc? This will show up if you search for Roc on https://search.nixos.org/packages
Examples:
"Fast, friendly, and functional programming language"
I'd just say "Fast, friendly, functional programming language"
I've got a package.nix file working on macos aarch64+x86 and linux aarch64+x86 now it's just the formalities :)
My PR is up on nixpkgs, please give it a thumbs up on github so it doesn't get forgotten in the ocean of nixpkgs commits :p
Last updated: Jul 06 2025 at 12:14 UTC