>The simple answer is... > >This system is an embedded system, with no CLI access. >All upgrades are done via an SNMP transaction that defines the >file to 'install', followed by a 'doit' command. > >Since one of the packages might be the kernel, As part of the 'install' >the system must successfully be running the new kernel. Well this >is Linux so the only way to run the new kernel is to reboot. >(Don't even suggest virtualization. :-) ) >PS. The SNMP based system also does not currently support a 'list of' >packages to be installed at a single time. I know you didn't ask for this level of feedback, but this really smells like the wrong design for the situation. You're trying to use rpm in a way that doesn't match its design - for example, there are circumstances where, because of dependencies, you cannot follow the one-package-at-a-time rule when doing something that amounts to an upgrade. Have you considered keeping an image of the system on a host which does have cli access and then re-imaging that onto the embedded target after applying changes? That seems to be a more common approach than trying to run a crippled package manager through an oddball interface on the embedded target itself. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
