[just_for_you]

>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 flawed 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.

[inferiorhuman]

Were it my responsibility I wouldn't worry too much about using FreeBSD binary packages in production. The way ports are set up, typically you'd have to go out of your way to install a bleeding edge version of something. If you're relying on something (e.g. ruby, python) with a bunch of commonly used versions you can alias the default to your preferred version. This may make audit compliance more difficult but not by much (especially considering how laborious compliance is anyhow).

At this point my biggest qualms about FreeBSD in production aren't really around the ports themselves but more around how much stuff has become Linux only (e.g. dockerify everything).

At megacorp we had to use an old version of CentOS (ugh) and the whole "keep updating ancient versions of third party software" thing came with plenty of caveats and frustrations. Regardless of the operating system it's not an approach I'd recommend.

Edit: Fink is the OSX port of dpkg more or less.