Bug 1056485 - [rfe] redo --force
Summary: [rfe] redo --force
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Radek Holy
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-22 09:50 UTC by Rahul Sundaram
Modified: 2019-03-04 07:28 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-12 13:43:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Rahul Sundaram 2014-01-22 09:50:33 UTC
Description of problem:

dnf history redo reinstalls the packages only if it has failed to install before.  I would like to have a way to force it to reinstall all packages in that transaction.  Currently, one way to do it is to run undo and redo again after that.

a recent example is 

https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriptlets_fail_during_updates

scriptlet errors and other types of issues in some packages are unfortunately not that common and it is useful to have something like dnf history redo --force  <transaction number> to have dnf reinstall those set of packages.

Comment 1 Ales Kozumplik 2014-01-22 12:05:18 UTC
Please take a look Radek. I don't even see 'dnf history redo' in our man page so perhaps we should start from there, defining the proper behavior of the operation.

Comment 2 Rahul Sundaram 2014-01-23 05:06:42 UTC
I just noticed that in yum, there is force-reinstall,  probably just follow that pattern

Comment 3 Rahul Sundaram 2014-07-22 17:32:30 UTC
Radek, do you need more information?

Comment 4 Radek Holy 2014-07-23 08:07:58 UTC
No. Not yet. I just need more time to finish other work :-(

Comment 5 Radek Holy 2014-08-19 11:13:54 UTC
It seems that 'redo' is not documented because it's not supported yet :-)

Comment 6 Radek Holy 2014-08-20 08:57:05 UTC
Well, we would have to define the sematics. If it means "redo the transaction", the forcing options do not make sense. If it means "restore the point in a history", it would have to have a completely different implementation than YUM has. And that's what "history rollback" does.

Comment 7 Radek Holy 2014-08-20 10:03:05 UTC
Hm, I meant it would have different *behavior* than YUM.
And as I think about it, "history rollback" also does not restore a given state always.
To sum it up, history subcommands do not deal with RPMDB states or original user requests. They are focused on concrete transactions that were performed in the past.

Comment 8 Rahul Sundaram 2014-08-20 13:36:34 UTC
Ok.  How about dnf force-reinstall then?  That would be compatible with yum

Comment 9 Radek Holy 2014-08-20 14:00:01 UTC
What do you mean? The only mention about "force-reinstall" in YUM's man pages is the "yum history redo force-reinstall" which is the "forcing option" I was talking about.
So you mean to implement a new command "dnf history force-reinstall" which does the same as "yum history redo force-reinstall"? Hm, as long as the "undo+redo" combo works, I don't think we need a new command. I'm not a fan of "shortcut commands".

Comment 10 Rahul Sundaram 2014-08-20 14:21:53 UTC
Well, lots of things in dnf are shortcuts.  reinstall for instance. they are implemented not just because they save time but also because sometimes packages have to be manipulated without affecting the dependent packages.

Comment 11 Radek Holy 2014-08-20 15:32:31 UTC
Good point. Then it's not just a shortcut. Let's find a good name for it. "Reinstall a transaction" doesn't make much sense :-)

Comment 12 Rahul Sundaram 2014-08-20 18:48:16 UTC
Does, rerunning a transaction and force rerunning a transaction make sense?

Comment 13 Radek Holy 2014-08-21 08:38:27 UTC
It makes sense, but I does not reflect the required action IMO. Well, in situations where you can run the transaction, it does and it's the purpose of "history redo". But what about situations where it can be run just partially or not at all?

Then you end up substituting the infeasible operations for install/reinstall/erase combinations. Because transactions are atomic, you are not running the transaction anymore, you are just trying to achive the same sets of installed and erased packages.

So, I'm thinking about something like "dnf history transaction-packages ID [reinstall] [reremove]". Even though the "goodness" of the name is questionable (at least the "reremove" :) ).

Comment 14 Rahul Sundaram 2014-08-21 13:02:08 UTC
I am not opposed to it.  However we need to use and enforce consistently the right (atleast the "same") terms within a project.  Please note that aliases in dnf is apparently not planned to be removed before becoming default (which is what I would have preferred) and the deprecation is on the term "remove" and not on erase (https://bugzilla.redhat.com/show_bug.cgi?id=963343)

I would argue that remove is far more popular and erase should be the one that would be deprecated and eventually removed but I would like to get some consensus on that before introducing new terms.

Comment 15 Radek Holy 2014-08-27 15:25:37 UTC
Hm, the more I think about it the more "history redo force-reinstall force-remove" makes sense for me. I just have to treat the arguments as a modifiers of the command's behaviour. However, I have not decided whether the modifiers will completely transform the transaction to just (re)installations and removals or whether it should work the Yum way: "clone the transaction as much as possible and substitude just the infeasible operations".

BTW, "dnf history redo" added by 80a23d216a880df1b4652d92aa0ec5cffcaf13e5 on master. Should appear in dnf-0.6.1.

Comment 16 Radek Holy 2014-09-12 13:43:59 UTC
Rahul, I had hard time with this bug. We need to keep reasonable amount of supported commands. The particular situation you have mentioned is not that common and it could not be solved by this command anyway. Such a command even would not be useful to repeat a broken transaction, because the transaction is recorded only when it succeeds. Also to reinstall packages that were part of a transation, you can still use "dnf history info ID" and "dnf reinstall PKGS..." then.

Unless you (and preferably someone else too) come up with a more common use case, I have to close this as WONTFIX.

Comment 17 Rahul Sundaram 2014-09-12 14:13:21 UTC
I will reiterate that package install script bugs are not that uncommon and force reinstall is a useful way to fix that problem when packages have dependencies or the transaction is complex and you don't want to retype it manually.  However there are workarounds and it is a huge problem.

Comment 18 Radek Holy 2014-09-12 14:38:47 UTC
Well, you said it's not that *common* in the original comment. I take the original word as a typo then.

Can you explain how it helps to fix the package install script bugs please? And why do you believe that the transactions are so complex in most cases and the affected users prefer the automatic "yum history redo force-reinstall" to manual retyping the broken packages in such situations? Why would they prefer reinstalling all the correct packages including the broken one to reinstalling just the broken package (taking into account that the transaction is in most cases as complex as you suggest)?

Comment 19 Rahul Sundaram 2014-09-12 18:24:43 UTC
Yes, that is clearly a typo. Let's look at the original reason why I wanted the feature

https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriptlets_fail_during_updates

You have a underlying cause here which is SELinux policy bug however a user would have simply run yum update which will pull in an arbitrary number of updates (this being Fedora that number is likely large).  Your solution is to extract the packages from the history and reinstall the packages however if the number of packages are more, this is tedious.  

Moreover, users typically run into such issues when they run yum update and time to debug a potential install script issue is rather high compared to just force running a transaction at a later point assuming one of the updates has fixed the problem instead of trying to cherry the precise update that fixes the issue.  Manual typing is feasible.  Just not that convenient.

Comment 20 Radek Holy 2014-09-12 19:03:45 UTC
Well, it did not solve that bug. You had to disable SELinux and upgrade the package to solve it. Sure, you could use "yum history redo ID force-reinstall" but why would you bother to find the appropriate transaction ID and why would you say "YUM, repeat the transaction" if you don't want the broken package again. So, in this case, it rather fixed the problems caused by that bug. OK, it would be useful in this case, but I hope that the same bug will never occur again.

Can you find another common situation when many people needed to "forcibly redo" whole transactions? I believe that in the other situations it was enough to reinstall just the one well known package and the package was very specific to the given situation. In that case, I don't think that the affected user would prefer to find the transaction ID, type "dnf history redo ID force-reinstall" and wait until all the packages are reinstalled instead of typing "dnf reinstall PKG" assuming that the PKG must be known in that situation.

Comment 21 Rahul Sundaram 2014-09-12 20:30:08 UTC
Let me give you another real life scenario:

I install Skype and since it doesn't just work if I install the package, I have to manually list some of dependencies.  I look up the set of dependencies and I install it.  Later, I upgrade or remove some packages and Skype breaks unexpectedly.  I want to get Skype working again urgently and I force reinstall the packages and figure out what broke it later.  Forcing that transaction is easier than manually relisting the set of dependencies.

Comment 22 Radek Holy 2014-09-15 08:14:55 UTC
OK, that makes sense too. However I think it should be reported to Skype maintainers and fixed there. It shouldn't be a standard workflow and thus a common use case. DNF is not here to debug and fix packaging issues.

Rahul, I understand your point. I agree such a command might be useful sometimes but I have to insist that these cases aren't/won't be so common. Let's keep this bug closed until enough interested users and use cases are accumulated. Or until someone writes a plugin.

For the record, if that happens, I also think about a command listing the packages installed/erased during a transaction that can be used in combination with "dnf install/erase" commands.

Comment 23 Rahul Sundaram 2014-09-17 19:56:40 UTC
Well, Skype was just an example and the problems have been reported to Skype and they haven't fixed it.  Have you seen what the latest supported version of Fedora even is?  It is unlikely we are going to have perfect packaging of third party software components or even repository packages and package managers support a whole lot of things including reinstall etc which wouldn't be needed if users and packages are in an ideal state. 

I wouldn't mind if this functionality was available as a plugin.  It is certainly one of the advanced use cases but invariably quite handy when I have needed them.  I will leave the bug report closed however.

Comment 24 Honza Silhan 2015-03-04 13:43:20 UTC
If anyone find the new use case other than executing the scriplets again, don't hesitate to share it, reopen this and we will reconsidered it.

Comment 25 dani 2019-03-04 07:28:27 UTC
I have a new use case.
Environment: Fedora 29 x64
On 03-03-2019 I performed the following action:

dnf distro-sync -y --best --allowerasing --refresh

This resulted in 169 packages altered including new kernel installation and old kernel removal.
This also resulted in a core dump at some point, but unclear which package caused it or failed to complete successfully.
After reboot, I have tried the following:
# dnf history list 262
ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
   262 | distro-sync -y --best -- | 2019-03-03 23:35 | E, I, U        |  169 ##
dnf history redo 262
Result: all packages already installed, nothing to do.
decided to try an undo/redo combo, in dnf shell to force single operation.
dnf shell
>history undo 262
Result - The old packages are unavailable, can't proceed (Error: no package matched)
>history rollback 262
Result - protected package (kernel) - won't remove (Problem: The operation would result in removing the following protected packages: kernel-core)

So I can't undo/redo, since I can't undo.
I have no idea which package caused the core dump, and the only relevant information returned by dnf history info 262 (aside from a complete list of affected packages):
Return-Code    : Failure: 1
With no indication as to which package resulted in that failure.

Currently I have a system with some package (or packages) mis-installed correctly, with no way of knowing which one failed, and according to you I would have to force reinstall individually 169 packages.
Does this warrant reopening this bug?


Note You need to log in before you can comment on or make changes to this bug.