All,
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:
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):
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.
Examples:
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.
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
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.
Examples:
- 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.