On 11/2/05, Fulko.Hew@xxxxxxxxx <Fulko.Hew@xxxxxxxxx> wrote: > > 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. > Eeek. Don't try that with glibc, you won't like the results. Or bash or any other number of packages critical to the systems functioning. If you do glibc will be gone, and good luck installing the new one (unless you have statically linked rpm, which as I understand has problems of its own). > 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. > Yes, rpm -U (its caps) buys the proper sequencing of install and erase, and removal of only files that were not placed on the system by the current transaction. Your basically doing the same thing we used to do on Solaris. Fortunately we did not have update libc except via Solaris patching mechanism. If we did our erase before install would have broken big time. You do realize that by not being able to run the complete set of rpms as one transaction, then its up to you to sort the packages by dependencies, and to do the check to see that all dependencies will be satisified by the end of the upgrade? If you can change this embedded snmp interface to take multiple packages as arguments in your interest. > > > 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 > ... > Yes, but your not using its most powerful feature which is its dependency checking of a given transaction against the current database state. And this is the feature that will, I am sure, unless your just ignoring the issues allow you to delete much of your own code (code deletion is a good thing) in favor of code that has been tested across many many machines and platforms. But at the end the day the choice poisen is yours. Good Luck...james _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
