JUjust_for_you·May 22, 2022
>pkg
pkg-ng is indeed a godsend, and I think I just got PTSD thinking about what Ports management was like before it. Currently getting flashbacks to the salad of utilities I used to use from ports-mgmt/.
>make
Yes, the Makefile infrastructure for both Ports/pkgsrc is clunky and slow, and the documentation is also terrible too. Took quite a bit of suffering to learn the dark art of properly authoring packages in pkgsrc.
For what it's worth, there's also the Gentoo Prefix project, but I haven't ever been able to use it because the bootstrap for it has failed every time I tried it on macOS or Linux.
At least for pkgsrc using it is as simple as:
$ git clone https://github.com/netbsd/pkgsrc --depth 1
$ cd ~/pkgsrc/bootstrap && ./bootstrap --unprivileged
$ cd ~/pkgsrc/misc/tmux && ~/pkg/bin/bmake install
$ ~/pkg/bin/tmux
As fla
Read the rest
wed and janky as pkgsrc is, it has at least worked consistently for me on macOS/Linux for years.
>compiling from source
Yeah, I agree. Compiling everything from source and using it in production is for insane people. Should have clarified that when I said "Ports/pkgsrc", I meant using official binary pacakges, and not necessarily building from source.
>latest and quarterly
The point of quarterly releases is to serve as a base for stable package versions, backported security fixes, and as a chance to fix package runtime/compilation issues before being generally available - something harder to do if you track bleeding-edge packages, where things can shift under people's feet.
It's also useful when building from source, like I do with pkgsrc for macOS, because lots of random things will break if there's too large of a rift between what's installed and what's in bleeding-edge pkgsrc. In these cases, you'd usually have to do mass rebuilds, and/or deal with dependency hell (eg, pkg X you have installed needs need <=libsomething-1336, but pkg Y in pkgsrc needs >=libsomething-1337).
I use the packages installed via pkgsrc pretty much daily on my MacBook, and it'd be really annoying having things possibly breaking after an update just a week apart, especially if I'm in a rush and need to get something done for work. So using a quarterly branch is useful, since it's a cadence I can stomach, and there's a higher likelihood that the devs had more time to polish the packages in that release.
>Fink
Never heard of this before. I'll give it a gander sometime soon.