Deterministic Software Install/Maintenance Method


Over the past few years have spent a significant amount of time (seemingly endless) on port/package maintenance tasks. It seems that we should be able to:
  • 100%: Use pkg for any/all installs and maintenance tasks (if no custom config options are required) -or-
  • 100%: Use ports for any/all installs and maintenance tasks (if any custom config options are required) -or-
  • Blended: Have a hybrid option whereby (preferred method):
    • Using port method, go through all dependencies for "config options"
    • Determine list of components where pkg version can be used (default options = matches pkg version) and process via pkg
    • Balance of components utilize ports for compilation to achieve specific requirements
The above would significantly reduce administrative overhead and time - making things much more efficient. Not sure if/why this has (or hasn't) been considered - as it "seems" like the pragmatic approach to optimize administration of FreeBSD based devices.

For reference, recently upgraded a device from 11.1 to 11.2. This spanned more than 3 days (background effort and numerous failures/restarts). Steps (roughly):
  • portmaster -af
  • Repeat:
    • failure occurs
    • determine if custom options are at play:
      • If no and "pkg delete" doesn't wipe out a litany of components = use pkg to upgrade/re-install
      • Alternatively (not "no" and not "yes") - fix port compilation/install issue (very time consuming)
      • if yes = go into port, make deinstall, make install clean
    • restart portmaster using output to pickup where it left off, excluding manually remediated package

Yes, this would likely require re-validation on update/upgrade if the options change in any way. But would happily sit through the initial "portupgrade --config" portion, knowing the total time savings because all port/pkg config options would enable optimal handling (pkg vs. compile). Possibly over simplifying this, but suspect that there are others who have same concerns around a more efficient means to handle software installation and maintenance.

  • Apache where specific module selections are needed must be handled via ports (make, portupgrade, portmaster, etc)
  • llvm where the software should be handled via pkg upgrade for efficiency/reduced time

If anyone has any thoughts on how this might be accomplished using the existing tools (pkg/portmaster/portupgrade/other?), would greatly appreciate the feedback - as it seems there isn't any specific data point to suggest if one could pkg vs. having to re-compile.

As reference, seem to frequently run into instances where a port won't compile correctly (default options) and simple work around is to use pkg (make deinstall && pkg install <package>). Recent example was git - ports version fails due to staging directory files not being setup correctly during make process (default options) - quick work around is to use pkg version to get back to working on the list of updates and upgrades. In this case, since it's the default options and dependencies don't become an issue - it's a "fix" to get back to moving things along.


Staff member
Did you have a look on 'synth'? Simply use freshports or the forum search function to dig up information about it.
Your git issue sounds more like a problem with git because you said it was a staging problem and ports aren't involved with that. pkg may have fixed the installation issue because it might have been a version or so behind the port. We run git daily for many years without issues.

The whole problem you speak of, otherwise, is the fact that ports and packages are brothers of the same mother but not exactly the same thing. You can think of packages as a convenience item provided for you enjoyment but convenience always comes at a price with anything and building packages means you get what's given sometimes.
You have described the perfect situation where "building a custom repo" is required. :)

IOW, you build a full suite of custom packages using poudriere or synth, which builds a package repo that you can then install from using the normal pkg tool.

You get all the benefits of custom options, with the simplicity of the pkg tools.
RE: git
  • Appears that as part of "make", it generates a staging directory and places files into a structure - that are then (later) copied into /usr/local for installation. However fails to instantiate all required files
  • In the end, it's simply one example of the type of things that have been encountered while trying to get things upgraded and maintained.
RE: synth
Will need to look into this. Sounds like it may meet the need. Was hoping to avoid adding "something else" into the mix, but may be necessary. Thanks for the info on this. Would be nice if it were part of the ports/pkg component and not reliant on an additional tool. That aside, if synth helps to cut down the lengthy maintenance and upgrade process - will certainly look into it.