On 11/1/05, Rob Riggs <rob@xxxxxxxxxxxxxxx> asked: > Hi Fulko, > > The rule requiring a reboot after each package install/remove sounds > absurd. 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. :-) ) Therefore since the system doesn't know what packages require a reboot, the SNMP based installer reboots after any and every package. PS. The SNMP based system also does not currently support a 'list of' packages to be installed at a single time. > Perhaps you can enlighten us as to why that rule and the "no > rpm -e" restriction exist. Because 'installation is a captured process', not a CLI, there is no access to the rpm command directly. I just looked at the code that was written, and the person does an 'rpm -e' on the old version of the package before an 'rpm -i' is done on the new version of the package. We also perform the same sequence of erase/install when an 'old' package needs to be installed. ie. Fallback to the previous version Actually, in all cases, if the system doesn't come back after the reboot mentioned above there is a mechanism to revert the 'cluster' back to the previous, working version. Perhaps I should re-visit how that part actually works. If thats truly the case, then an 'rpm -u' doesn't actually buy me anything as long as the "%obsoletes" clause removes the 'other' packages. > Why are you even using RPM? With these restrictions it's bloody useless. Even with restrictions (pre-defined sequences), RPM is still very useful because its an enabling technology that: - is already written - has a standard package format - maintains its own database - supports versioning - is a known (mostly-documented) entity ... _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
