Ports vs updates


When I upgraded TrueOS recently, it seemed to replace all of the packages I had installed via ports with versions from the TrueOS repos, those packages using different build options to those I need. It says in the handbook that TrueOS system update cannot be used if any packages are locked and I’ve read elsewhere that pkg can’t tell packages installed via ports from those installed from the TrueOS / FreeBSD repos hence it seems doing system updates is all or nothing and that everything installed from ports has to be at least manually re-installed, if not also rebuilt, after every system update, right?

It seems a shame to me that users have to pick between being able to do automated system updates or being able to lock ports/packages. Is my understanding of the situation correct? Is there anything on the pkg or trueos updater roadmap that could improve this situation so that (at least some) packages/ports can be locked yet we can still perform system updates? It should be possible to lock all packages/ports that don’t have any reverse dependencies (as is the case with many apps) and still do automated mostly full system upgrades.


I uinderstand that sometimes a library/dep will get a major update a break compatibiilty with certain ports but we should be allowed to take such risks. That’s what we have boot envs for!


The devs can answer “is there anything on the roadmap”, but I come from a long time use of FreeBSD and when you update your base, you should be at least rebuilding all your ports. I understand the appeal of building ports yourself so you can tweak options, but at the moment, pkg doesn’t make a distinction between a binary port you pulled down and installed and one you built from a local source tree.
The updates from TrueOS is effectively you doing:
update base source tree
make buildworld && make buildkernel && make installkernel && reboot && make installworld
update ports tree
rebuild all installed ports

So the fact that you are getting both updated base and ports tree is an important piece to remember.


The TrueOS update mechanisms have those limitations for a few very good reasons:

  1. Due to being based on FreeBSD’s “Current” branch, there is no guarantee of ABI compatibility. The updater will check if the new/old packages are ABI compatible right at the start, and if there is a mismatch it will make sure that all system packages get re-installed in order to ensure compatibility with the system ABI (otherwise you will have widespread breakage in all your non-ABI-compatible packages after the updates).
  2. The “lock” functionality in pkg is nice in theory, but causes havok with the update mechanisms in pkg - even on FreeBSD. That is the “original” reason why we have always disabled any pkg locks at the outset of the update process - back from the PC-BSD days.


  1. With the new 6-month STABLE release track for TrueOS, this will ensure that your system ABI does not change for 6 months, allowing for incremental updates during that time period as needed.
  2. We are looking into alternative ways to treat “locked” packages at upgrade time but have not settled on one yet. One idea that I have been floating was to treat locked packages as the users “required” packages - so the upgrade will only succeed if those same packages are still available/installed afterward. That won’t address your ports vs packages issue though.
  3. You could always build your own local package repository using poudriere or synth, and add that as an additional “higher-priority” repo in your configuration. That will let the updater be able to use your custom packages, but you will have to be careful of the ABI breakages and rebuild your repo as needed as well.


Thanks for your replies mer and beanpole!

Sounds like I may have to give synth or poudriere a go soon.


And something I just realised here is that that downloading etc. is going into a new BE, not your current BE. When updating is finished you should have a whole new BE and it should be activated so that it is what you will boot into. The BE you are in currently will have all the ports you built and you will be able to switch back to it ( especially if and when the new one fails or doesnt give some desired or expected result ) any time you wish.
That is the beauty of ZFS. keeping a fallback system ready to use.
Just remember you’creating almost a whole new TrueOS but that will use your old user /usr/home/enviornment.
Think of it as creating a Freebsd system with a separate /usr partition and installing Freebsd on a new partition about every month but using the old /usr in your /etc/fstab. .after 2 total updates you would have to go back and wipe an old partition to put the new Update into. ZFS lets you decide on how many old enviornments to keep with 5 being the default but easily changed.
Hope this explains a little and that I havent left something important out or misrepresented something somewhere.