Ports or packages without flames

I know this has probably been asked and answered a million times and it's in the handbook, too, but It's 2020, and I've been running FreeBSD on and off for a decade or so. I've run it at home as a server for most of that time and so I have the ability to configure stuff and keep it running. Now, I'm running it on my T430 as a desktop... well, I prefer the console, so it's TWM most of the time, but I do have KDE installed. I'm trying to get to where I'm running FreeBSD 80% of the time (It's really, really hard to give up my Mac OS world). As part of my transition, I'm trying to decide if I need ports for anything beyond the occasional "there's no package for X, so let's install the port for X," which is what I do these days, and it's as confusing today as it was a decade ago. So, here's the updated question(s) I've been thinking about:

1. In y'all's varied opinions, what are the tradeoffs to using ports or packages in the modern era?
2. Is it reasonable to use ports for everything except KDE/X/other honking big packages?
3. Should one stick to one or the other, or is it fine to mix the two willy-nilly?
4. How long does it take (roughly) on a modern workstation type laptop (not a chromebook) with SSD to portmaster print/tex-live?

Really, I'm just trying to wrap my brain around why a desktop user/aspiring power user would build ports from source that take hours to compile vs a few minutes to install from packages?

Is that/should that be the main differentiator?
 
It was actually asked... And you'll get a million answers. :)

I use packages for all my systems. Use ports if you want a specific configuration for a given software but if you need this, it's better to only use ports. Don't mix them unless you know exactly what you do.

Packages are quick to install, quick to upgrade and usually make no error of any kind. A sort of peace of mind. You find the same about custom compiled kernels versus generic ones.
 
1.) packages are fine and spare you a lot of trouble, ports make sense when you want to adjust build-time options, or, of course, when you need some software that can't be provided as a packages for legal reasons
2.) No, IMHO
3.) Rule of thumb is: don't mix. You can mix, if you know what you do. One key element is, that ports and packages should be based on the same branch. pkg comes pre-configured to use the "quarterly" branch, while portsnap will give you a snapshot of the "latest" branch. Mixing that will break for sure.
4.) I have no idea. I use poudriere to build my own pkg repo, and with around 1500 packages in that repo and ccache installed and used by poudriere, a "large" build takes around 30 to 40 hours. I have a private server running 24/7 and a jail on that responsible for package building, so I don't care TOO much ... I wouldn't recommend portmaster, btw.
 
I have a private server running 24/7 and a jail on that responsible for package building, so I don't care TOO much ...

This makes a lot of sense. I was only thinking of building on my desktop, of course that's a great use for the otherwise idle server I use for scm.
 
I use packages for all my systems. Use ports if you want a specific configuration for a given software but if you need this, it's better to only use ports. Don't mix them unless you know exactly what you do.

OK. So, what do you do when a package is only available via source or ports and isn't in pkg?
 
I use mostly packages but then the occasional ports for any latest software I specifically care about such as Blender or Emscripten.

If you do want to mix packages and ports like this, it is *important* that dependencies for i.e Blender are all manually installed from packages and only the Blender port is installed. Don't just hammer in 'make' and let it recursively make a mess of your system.

So "leaf" software as ports but everything else as packages. You can use things like $ make pretty-print-build-depends-list to help work out what dependencies you need to build a port.

This works because packages are "hardcoded" to require specific versions of dependencies that ports obviously screw up. If you simply use ports for software that is never going to be a dependency, you can sidestep the entire issue.
 
  • Like
Reactions: a6h
I primarily use pkg(8). Here's an example where I needed to use ports on top of a pkg exclusive install.

I wanted to use subversion with SASL authentication. SASL is omitted in the default pkg build. So I built and installed it from ports with SASL enabled.

Six months later - pkg upgraded a dependent library that broke subversion. I got by using svnlite(1) until I figured out the problem (with help from this forum) and rebuilt svn from ports.

Here's one strategy to deal with a limited mix of ports on top of packages.

  • Use the quarterly pkg repository.
  • Every quarter expect to rebuilt the one or few ports.

That should make predicting when things may break easy. There are likely circumstances where this won't work - which I have not yet seen myself.
 
Back
Top