Closed evgeni closed 7 years ago
Broken Koji is broken :'(
So the hope here is that there is no one package in the mix that breaks the remove or if there is users have to stop and figure out how to solve the issue? What if a package being removed is being used by something on the box that the user has added and wants to keep around? Do we tell them to run this command manually removing the one or two packages from it?
No, we currently just tell the user that a whole bunch of packages is to be removed, and ask for confirmation (but the list we ask is not really complete, tbh). After that we just run the command. Previously in a loop, now just one go. So there is no behavior change as such present.
Also the old and the new code don't check if yum was successful removing the packages.
Right, but in the previous iteration it would try and delete each package and only those that failed would be left around correct? This does change the behavior to fail out of removing any packages if one fails?
@ehelms - Ah, so if one package fails, the entire command fails?
@ehelms This doesn't change the behavior. If any fail yum will print a list of Failed packages just like it will print a list of Installed ones after every transaction. https://github.com/rpm-software-management/yum/blob/master/output.py#L1734-L1742
Example of Installed output below, I cannot find any Failed output online.
EDIT: This is actually exactly how it use to work before it was re-written in Ruby. https://github.com/Katello/katello-packaging/blob/e1a51759744f7826c9a02037551a51227b884b9a/katello/katello-remove#L166
[test]
Fair enough - I just to make sure that troubleshooting was not being sacrificed for speed in an operation that should not be performed that often to warrant optimizations in lieu of the ability to.
A small benchmark on CentOS7 with 272 packages to be removed:
without the patch:
with the patch: