On 11/1/05, Rob Riggs <rob@xxxxxxxxxxxxxxx> wrote: > Hi Fulko, > > The rule requiring a reboot after each package install/remove sounds > absurd. Perhaps you can enlighten us as to why that rule and the "no > rpm -e" restriction exist. Why are you even using RPM? With these > restrictions it's bloody useless. Agreed. The thing you have to realize (and I think your client or boss or whomever) is that packages have dependencies on one another. The best and fool proof way to handle these dependencies (or relatioins in a partial ordering if you like...sorry been reading Knuth) is install/erase/upgrade packages in one transaction that has the property of dependency closure met (i.e. all requires are provided for either in transaction or by what is in the database and will be there after the transaction runs). > I would think that it would not be possible to run an RPM command from a > pre/post script because there would be a deadlock on the RPM database. You can at least in 4.x versions of rpm. Jeff added concurrency support a while back. The problem with this approach is that rpm is not aware of inter transaction dependencies, and what you in effect are doing is running a transaction inside another transaction, but since it would be a seperate invocation of the rpm cli, there is no way for librpm to know that really (oh, maybe there is, but somewhere in the universe KISS must be adhered to). > That's just speculation on my part though. > I would also think that you would need to be able to perform an rpm -U > (upgrade) in addition to rpm -i (install). > Here's an idea: just install the new package with "--replacefiles" and > just leave the deprecated packages there. (It's ugly as hell, but no > less ugly than using RPM with those rules and restrictions.) > Yeah but at the end of the day what is the goal of these scary requirements, just what are you trying to avoid? Also, there are some packages that just have to be upgraded in a set/transaction. Any time the critical software on the system depends on some other piece of software (in different packages of course), and the api of the depedent software is changed you typically have this situation. So I suspect your going to run into problems even if you do implement this somehow. Oh and by the way, and upgrade is an install of the new package followed by an erase of the old package, so doing upgrades will take care of many of your erases, and as Rob said, Obsoletes can take care of the other non-related erases. Cheers...james _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
