Some bits of code you might find interesting

[truist]

https://github.com/truist/settings/blob/master/bin/util/pkg_comp_util.sh is a set of utility functions, including a "hygiene" function, to help catch errors/issues with the build builds. Maybe some of it will be useful to you.

https://github.com/truist/settings/blob/master/bin/server/pkg_comp_wrapper is my new interface to day-to-day usage of pkg_comp. It ensures I always start with a clean (but pre-created) sandbox, and then actually confirms that all the desired packages were built, and then leaves the sandbox behind (so I can inspect the errors) if they weren't. I'm also going to try running it (with no args) instead of pkg_comp4cron in my weekly cron job.

If that works, I think I'm going to fall back to bare pkg_comp instead of pkg_comp-cron. pkg_comp-cron was great for helping me get set up, but now that I've essentially merged the two packages (via shared configuration and a manual cron job), it seems extraneous.

All of this is just in the spirit of sharing ideas and "real-user" feedback; I don't have any specific critique or suggestion for pkg_comp. So feel free to close this issue; this was just the best way I knew to draw your attention to these things.

[jmmv]

I'm curious about the pkg_comp_wrapper workflow that you describe: if you end up having to wrap pkg_comp to "simplify" its execution, then there is something wrong with pkg_comp. I'm wondering if we'd distill those into specific feature requests if you haven't done so already.

(I myself have found many rough edges recently when trying to set up a clean NetBSD box from scratch... and those are all things that ought to be fixed. I feel they line up with what you are trying to automate as well.)

[truist]

pkg_comp_wrapper provides a few features that aren't provided by pkg_comp:

1. It fails the build if any desired packages are missing. (It doesn't check for dependent packages, which should probably be rectified.) This is Issue Failed/missing packages are not reported #7.
2. It leaves the sandbox behind, only in the case of a failed build, so the logs can be examined. This is issue Unclear how to access build logs #3.
3. It automatically runs pkgin update because that way I don't have to remember to do so. (No issue; this probably doesn't belong in pkg_comp.)
4. It manually checks (up front) the list of desired packages to be sure they all exist, so it fails fast in case of a typo. (No issue; pkg_comp does eventually fail gracefully in this circumstance, I think.)
5. It uses flock to be sure it doesn't disturb an existing build, and to fail fast if there is one. (No issue; I think pkg_comp fails gracefully in this case, too, eventually.)