On 10/14/2018 2:36 PM, Brett Lymn wrote:
I've been "manually" invoking everything that I want/need to run and capturing any errors logged to sort out what might be missing.Right - atf can automate this bit for you. If you are doing a customised build then you will want to do this agin if/when you update to make sure things are not broken afterwards. It means you can validate things in a consistent and repeatable manner.I think that's more than I need. I'm going to pick *a* release and stick with it (for a very long time -- updates will be difficult). The bigger concern is deciding that I need to add some particular binary to this "distribution". Adding shouldn't break anything that already works but could require additional dependencies that haven't been present, prior to that point.OK, if you say so but manually bashing through all the tests time after time just to track down some obscure crash is pretty tedious in my mind. You probably should think seriously about maintaining the image even if it is for back-porting security updates.
You're used to dealing with "computers" where you CAN change a piece of software AFTER release. I deal with devices/appliances where the cost of upgrading the device far exceeds the cost of the device (and comes at a huge "reputation cost" in the eyes of the user: "You mean, this device has been BROKEN all of this time?") I'm exploiting the fact that I can throw a NetBSD system onto some COTS hardware (without requiring it to be a "PC"), embelish it with outboard devices (so I don't have to get monies approved to build prototypes) and pitch a proof of concept prototype to Management -- to fund REAL development efforts. The NetBSD variant will then be unceremoniously scrapped (it would be silly to deploy something as big and bulky and likely to need continued updates in the future when we have our own codebase that addresses our needs far more precisely). I just have to ensure that the NetBSD-variant of the device "appears" to perform all of the basic functions (so Management can actually "tickle" the prototype and elicit the expected responses/behaviors) and have a valid explanation for those that the device can't perform.