Spack, at least, is also very much at home outside the HPC environment. Works on macOS and Windows (though Windows packages aren't quite as mature as Linux and macOS). Doesn't require environment modules to use.
Also, latest Spack builds in parallel. You can do that with pkgsrc using external tools like Bob [1], but Spack sets up a GNU jobserver, which LLVM and ninja now support in addition to gmake. So you get very dynamic parallelism. See the FOSDEM talk [2].
It is. Probably an even greater gift to earth from the NetBSD community than NetBSD itself. The ability to run recent packages on most arch without them forcing you to use NetBSD, but allowing you to keep the original OS in many cases if you want, is mind-blowing.
Yes, I really like pkgsrc. It is too bad Linux distros did not embrace pkgsrc, instead we have more package managers then one can imagine. Having one common pkg manager would have made new user adoption easier. But seems Linux does not care about portability these days :(
This is one other thing I get, it is part of a audit report mailed out on my NetBSD system showing vulnerabilities of packages installed via pkgsrc. Yet another thing Linux is missing.
Date: Thu, 16 Jul 2026 18:10:08 -0400 (EDT)
From: Charlie Root
To: my_id@localhost
Subject: Installed package audit result
Package x265-4.1 has a denial-of-service vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2017-13666
Package gd-2.3.3nb17 has a denial-of-service vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2021-38115
Package gtar-1.35 has a directory-traversal vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2025-45582
> Half the time I delete the program I was testing out anyway, but then I’m stuck with this extra stuff in my base system.
"apt autoremove", no?
> I never really even stopped to think that there might be way to separate out the “base system” from the other crap I’ve installed along the way.
That's the Windows-way, not the UNIX-way. /s
> Even better, pkgsrc lets you use it in unprivileged mode and install stuff locally in your user’s home directory like ~/pkg. This can give your user their own separate custom userland from other users.
A nascent form of containerization (but without, you know, all of the actual isolation). Also, I am fairly certain e.g. dpkg can do this too.
> Pkgsrc isn’t really a package repository itself. It is simply a collection of Makefiles that define how to build each package as well as the dependencies needed for a package. Each package’s Makefile defines where to download the source code for the package, how to apply any necessary patches, and then how to build it.
Ah, and now the ugly parts. How much value is all of this anyway, compared to fetching the tarball from the project's site and running make on your own? I guess the "patches to apply" is the most valuable part of all of this.
> One potentially “irrational” requirement of mine was that I wanted to be able to install software from my own network in case the internet ever goes down. Not just my internet, but THE internet. And I know that the internet as whole will probably never really go down, but I do think it may get to the point where the internet is fragmented into completely different silos because of government censorship.
I'm fairly certain it already has happened in a couple of places, and it doesn't looks like the trajectory is gonna change.
> Ah, and now the ugly parts. How much value is all of this anyway, compared to fetching the tarball from the project's site and running make on your own? I guess the "patches to apply" is the most valuable part of all of this.
it is a standard way, well documented. And local. Suppose you need a new minor version quickly of a package or a dependency... with traditional package managers you have different versions of difficulty setting up the build environment (I have done rpm and pkgsrc packaging alike, also portage), and it may be pretty involved to do an update of a dependency somewhere. pkgsrc (and ports style package management) is really handy if you need to do some custom stuff in a no-fuss way.
Also if you have compiled a fair amount of packages, you know painful it can be sometimes, broken automake config, random esoteric build tools, and if ever had to target non-linux, then all of these are amplified.
IMHO pkgsrc is relatively simple to comprehend, and easy to get started, compared to other build packaging solutions. Not as fast or fancy, but very rugged and can work "offline" as other comments called out.
> How much value is all of this anyway, compared to fetching the tarball from the project's site and running make on your own? I guess the "patches to apply" is the most valuable part of all of this.
For one package not much. For a package with dependencies (that you don't already have), quite a bit of value.
In a similar vein, Spack and Easybuild are similar (more recent) build systems which are often used in the HPC space.
* https://spack.io
* https://easybuild.io
Spack, at least, is also very much at home outside the HPC environment. Works on macOS and Windows (though Windows packages aren't quite as mature as Linux and macOS). Doesn't require environment modules to use.
Also, latest Spack builds in parallel. You can do that with pkgsrc using external tools like Bob [1], but Spack sets up a GNU jobserver, which LLVM and ninja now support in addition to gmake. So you get very dynamic parallelism. See the FOSDEM talk [2].
[1] https://github.com/jperkin/bob
[2] https://archive.fosdem.org/2026/schedule/event/DHUQAN-spack-...
It is. Probably an even greater gift to earth from the NetBSD community than NetBSD itself. The ability to run recent packages on most arch without them forcing you to use NetBSD, but allowing you to keep the original OS in many cases if you want, is mind-blowing.
It's funny to see someone discovering things that are obvious to me since I've been around a bit longer (like what tarballs are for).
> I don't know how to make debs and rpms
There is tool called nfpm for easy package creation.
Another one of the underdogs I seem to like to pick. I find it so much more elegant than homebrew.
Fight the hegemony!
Yes, I really like pkgsrc. It is too bad Linux distros did not embrace pkgsrc, instead we have more package managers then one can imagine. Having one common pkg manager would have made new user adoption easier. But seems Linux does not care about portability these days :(
This is one other thing I get, it is part of a audit report mailed out on my NetBSD system showing vulnerabilities of packages installed via pkgsrc. Yet another thing Linux is missing.
> Half the time I delete the program I was testing out anyway, but then I’m stuck with this extra stuff in my base system.
"apt autoremove", no?
> I never really even stopped to think that there might be way to separate out the “base system” from the other crap I’ve installed along the way.
That's the Windows-way, not the UNIX-way. /s
> Even better, pkgsrc lets you use it in unprivileged mode and install stuff locally in your user’s home directory like ~/pkg. This can give your user their own separate custom userland from other users.
A nascent form of containerization (but without, you know, all of the actual isolation). Also, I am fairly certain e.g. dpkg can do this too.
> Pkgsrc isn’t really a package repository itself. It is simply a collection of Makefiles that define how to build each package as well as the dependencies needed for a package. Each package’s Makefile defines where to download the source code for the package, how to apply any necessary patches, and then how to build it.
Ah, and now the ugly parts. How much value is all of this anyway, compared to fetching the tarball from the project's site and running make on your own? I guess the "patches to apply" is the most valuable part of all of this.
> One potentially “irrational” requirement of mine was that I wanted to be able to install software from my own network in case the internet ever goes down. Not just my internet, but THE internet. And I know that the internet as whole will probably never really go down, but I do think it may get to the point where the internet is fragmented into completely different silos because of government censorship.
I'm fairly certain it already has happened in a couple of places, and it doesn't looks like the trajectory is gonna change.
> Ah, and now the ugly parts. How much value is all of this anyway, compared to fetching the tarball from the project's site and running make on your own? I guess the "patches to apply" is the most valuable part of all of this.
it is a standard way, well documented. And local. Suppose you need a new minor version quickly of a package or a dependency... with traditional package managers you have different versions of difficulty setting up the build environment (I have done rpm and pkgsrc packaging alike, also portage), and it may be pretty involved to do an update of a dependency somewhere. pkgsrc (and ports style package management) is really handy if you need to do some custom stuff in a no-fuss way.
Also if you have compiled a fair amount of packages, you know painful it can be sometimes, broken automake config, random esoteric build tools, and if ever had to target non-linux, then all of these are amplified.
IMHO pkgsrc is relatively simple to comprehend, and easy to get started, compared to other build packaging solutions. Not as fast or fancy, but very rugged and can work "offline" as other comments called out.
> How much value is all of this anyway, compared to fetching the tarball from the project's site and running make on your own? I guess the "patches to apply" is the most valuable part of all of this.
For one package not much. For a package with dependencies (that you don't already have), quite a bit of value.