Hide Forgot
Description of problem: yum installs everything and, then, cleanups everything. It should install and clean each package at time. It would be a lot easier to manage installation interruptions in this way; only one package would be, potentially, broken. Version-Release number of selected component (if applicable): any How reproducible: Just upgrade a few packages. Steps to Reproduce: 1. Open a terminal 2. su -c 'yum upgrade foo bar baz' Actual results: yum will install each package and, then, clean up Expected results: yum should install foo and clean foo; install bar and clean bar... Additional info: urpmi and smart use this technique. It's definitely better, IMHO.
This is not yum, but rpm there is processing the transaction and the whole update transaction will complete, before the leftovers is cleaned up. I dont see why cleanup after each update package would be better ?? Doing the update and cleanup when the update is done, make sense IMO.
(In reply to comment #1) > This is not yum, but rpm there is processing the transaction and the whole > update transaction will complete, before the leftovers is cleaned up. > I dont see why cleanup after each update package would be better ?? > Doing the update and cleanup when the update is done, make sense IMO. Ok, picture this: I'm doing a yum upgrade -y after a while and 50 packages get upgraded. In the middle of cleanup #2 (after installing 50 packages), lights go out/kernel freezes/the connection is cut (in case of doing it by ssh)... etc... you get the idea. I end up with 48 duplicate packages and this causes a lot of trouble. In the other case, if yum passed a single file to rpm and did one installation and one cleanup at a time, I'd end up with 1 duplicate package no matter what. IMHO, this is better than the former, don't you think?
Many many years ago rpm used to perform erasures (ie the "cleanup" you see in yum) right after installs. It was changed to how it is for a reason: doing erasures right at the end keeps the system in a more functional state while the transaction is running, and helps avoiding a total system meltdown if an upgrade is aborted in the middle. If the transaction was aborted right after a core library got updated with a soname change (and the old version removed immediately afterwards), it'd require rescue disk to recover to a workable state. Cleaning up duplicates afterwards is a walk in the park compared to that. Rpm does need a better recovery from aborted transactions, but changing the way erasures are done is not a part of that.
(In reply to comment #2) > (In reply to comment #1) > > This is not yum, but rpm there is processing the transaction and the whole > > update transaction will complete, before the leftovers is cleaned up. > > I dont see why cleanup after each update package would be better ?? > > Doing the update and cleanup when the update is done, make sense IMO. > > Ok, picture this: > > I'm doing a yum upgrade -y after a while and 50 packages get upgraded. In the > middle of cleanup #2 (after installing 50 packages), lights go out/kernel > freezes/the connection is cut (in case of doing it by ssh)... etc... you get > the idea. > > I end up with 48 duplicate packages and this causes a lot of trouble. > > In the other case, if yum passed a single file to rpm and did one installation > and one cleanup at a time, I'd end up with 1 duplicate package no matter what. > yum logs the transaction, so you can run the 'yum-complete-transaction' tool to finish the aborted transaction :) An Panu described the reason why it works that way.
(In reply to comment #3) > Many many years ago rpm used to perform erasures (ie the "cleanup" you see in > yum) right after installs. It was changed to how it is for a reason: doing > erasures right at the end keeps the system in a more functional state while the > transaction is running, and helps avoiding a total system meltdown if an > upgrade is aborted in the middle. If the transaction was aborted right after a > core library got updated with a soname change (and the old version removed > immediately afterwards), it'd require rescue disk to recover to a workable > state. Cleaning up duplicates afterwards is a walk in the park compared to > that. > > Rpm does need a better recovery from aborted transactions, but changing the way > erasures are done is not a part of that. I'm sure you, guys, know a lot more about these kinds of things than me. Thank you for taking the time to explain this. I'm sure urpmi and smart considered this too. For example, urpmi installs chunks of packages (I imagine that it installs dependencies and central/main packages at the end) and cleans in the same order. Smart, on the other hand, does one by one. Just consider what others are doing; for the sake of diversity and openness. ;=) Consider this my last reply; don't want to bother you or anything. Thank you for considering this request.
(In reply to comment #5) > I'm sure urpmi and smart considered this too. For example, urpmi installs > chunks of packages (I imagine that it installs dependencies and central/main > packages at the end) and cleans in the same order. Sounds like urpmi does many small transactions instead of doing it all in a big lump like yum. The advantage is of course "limited damage" in case something goes wrong, but the downside is that it can hit problems with file conflicts and disk space when already committed to a transaction (unless it first does a test transaction with the entire package set and only if no problems are found, slices up the transaction to smaller pieces and proceeds). Doing this can also have unwanted side-effects on %pretrans and %posttrans scripts and such, but that depends on the actual packages. > Smart, on the other hand, does one by one. Smart does its own ordering, unless told to use rpm's order with a config option, OR if it finds a dependency loop it's not able to cut. The original reason for it doing ordering on its own was that older rpm versions didn't do erasure ordering, which was kinda understandable, but nowadays very much unnecessary and even harmful in worst case. I find it rather peculiar that it so completely changes the way ordering is done, even more so considering it can then fall back to the rpm way of doing things. So you get one of two completely different behaviors depending on what happens to be in the transaction set, which is not a good thing.
> I'm sure urpmi and smart considered this too. For example, urpmi installs > chunks of packages (I imagine that it installs dependencies and central/main > packages at the end) and cleans in the same order. We've been looking at doing this for a long time, in yum. My current attempt is a plugin: http://james.fedorapeople.org/yum/plugins/updater.py ...which mostly does the right thing, by installing a "minimal chunk" of packages when run. But has two problems: 1. You need to run yum multiple times, which isn't ideal. 2. If it hits a problem, there's no automated way to make it move onto the "next chunk". ...you can try it now (I think it works fine on RHEL-5), and give some feedback.