At the company I work for, we're designing a provisioning system especially suited for the thousands of devices that we need to be able to safely deploy applications and configurations on, most of which run Linux with stringent ram, non volatile memory and bandwidth constraints, whilst others run Windows with less stringent constraints.

One of the requirements to meet is that upgrading an installed application and/or its configuration should be a transactional operation: anything that should happen to the device while it's updating itself should leave the device in a coherent state: say the device turns off in the middle of an update, while it has already upgraded half of the files but left untouched the other half, when the device boots up again it has to be able to either continue upgrading or go back to the state it was when the upgrade process started.

I've looked at already existing package managers: dpkg doesn't seem to be able to do what I want, whilst rpm does have some sort of transaction:

If any of the packages fail to install, the rpm command will not install any packages. All of the packages will be installed, or none.

But from the quote above it's not clear to me what happens if the computer crashes or shuts down while the transaction is in progress. This answer to a similar question on unix.stackexchange.org seems to confirm that rpm alone cannot do what I want, whilst yum in theory should, via the yum-complete-transaction command. I've however read horror stories about that command.

Thus, as far as you know, does anything like what I described above already exist? If so, what would your suggestions be? Does yum with yum-complete-transaction meet my requirements, and does it do that reliably?

For my specific needs, it has to be an OSS product, portable or already ported at least to Windows and Linux, with a commercial-friendly license - but if a product with another license exists I'd be interested to know anyway.

  • Might help to mention which OS is running on those embedded devices ;) – Izzy May 2 '16 at 5:11
  • The OS is linux but the tool has to be portable. In the worst case, one could attempt a port. Thanks for the pointer though, I'll edit my question. :) – Fabio A. May 2 '16 at 9:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.