Package creation is complete for DPM. I need QA testers. It also needs a wave of cleanup of the output as some of the output can be redundant.
But, this is rapid progress nonetheless. For me, anyway.
Next needs to be package signing and checksum verification module. These can be bundled into one module.
After that would be two modes of package installation. One that is “secure”, i.e. has the openssl/gpgme dependencies and the algo support those provide, and is intended for the normal secure operation of DPM.
The other missing mode is an insecure install module that is used for barren environments for bootstrapping to the point that the secure module can be installed along with its dependencies. That way if openssl/gpgme isn’t installed yet, those package can still be installed without checksum verification or signing verification, and then the secure module can be installed on top of that, and then that can be used to install the signing and checksum verification module, and then those packages can be validated.
What I might do here is have the basic package installation module be called “package-core”. It just installs packages. Then a “package” module that expects to have signing support. This would basically work the way the dpm core system works, the “package” module would load the package-core module, and the “verify” module, and execute their entry points to bring it together without forced re-implementation of all the moving parts.
So I guess verify, package-core, package. And then I can bring in DON for remote repository interaction, which, of course, will require the creation of repository management tools. It’s alot of work, but I still think this is the best path.
Edit: After working through through it a little more, it should be fine to have the build module expose the seal and unseal functionality, have the verify module expose its verification functions for signatures and checksums, and then have the install module call those loaded symbols if they exist. While this would introduce a little complexity with module dependency management, this allows both basic functionality with minimal dependencies and extended functionality when those dependencies are available, so the only thing to worry about is installing the modules in the right order after bootstrapping which is fairly trivial.
There’s an optional development path after this. An “SDPM” package type would be useful to have for chain of custody assurances on automated build systems in some scenarios. I really don’t want to introduce this at this point, though, and am still debating doing it. Looking how RPM-based OS’s do this, it’s always overengineered, ambiguous, and usually more pain than it’s worth.
Vacation Time!
Vacation is coming up, for April 19th – April 25th.
After a bunch of back and forth, I’ll be in TAMPA for a couple days to get some sun, and then CENTRAL MAINE for a few days of game hunting. 🙂