Implement history command

[mcurlej]

Command: history Aliases: hist

The history command allows the user to view what has happened in past transactions and act according to this information (assuming the history_record configuration option is set).

dnf history [list] [--reverse] [<spec>...]

The default history action is listing information about given transactions in a table. Each <spec> can be either a <transaction-spec>, which specifies a transaction directly, or a <transaction-spec>..<transaction-spec>, which specifies a range of transactions, or a <package-name-spec>, which specifies a transaction by a package which it manipulated. When no transaction is specified, list all known transactions.

--reverse

The order of history list output is printed in reverse order.

dnf history info [<spec>...]

Describe the given transactions. The meaning of <spec> is the same as in the History List Command. When no transaction is specified, describe what happened during the latest transaction.

dnf history redo <transaction-spec>|<package-file-spec>

Repeat the specified transaction. Uses the last transaction (with the highest ID) if more than one transaction for given is found. If it is not possible to redo some operations due to the current state of RPMDB, it will not redo the transaction.

dnf history replay [--ignore-installed] [--ignore-extras] [--skip-unavailable] <filename>

Replay a transaction stored in file <filename> by History Store Command. The replay will perform the exact same operations on the packages as in the original transaction and will return with an error if case of any differences in installed packages or their versions. See also the Transaction JSON Format specification of the file format.

--ignore-installed

Don’t check for the installed packages being in the same state as those recorded in the transaction. E.g. in case there is an upgrade foo-1.0 -> foo-2.0 stored in the transaction, but there is foo-1.1 installed on the target system.

--ignore-extras

Don’t check for extra packages pulled into the transaction on the target system. E.g. the target system may not have some dependency, which was installed on the source system. The replay errors out on this by default, as the transaction would not be the same.

--skip-unavailable

In case some packages stored in the transaction are not available on the target system, skip them instead of erroring out.

dnf history rollback <transaction-spec>|<package-file-spec>

Undo all transactions performed after the specified transaction. Uses the last transaction (with the highest ID) if more than one transaction for given is found. If it is not possible to undo some transactions due to the current state of RPMDB, it will not undo any transaction.

dnf history store [--output <output-file>] <transaction-spec>

Store a transaction specified by <transaction-spec>. The transaction can later be replayed by the History Replay Command.

Warning: The stored transaction format is considered unstable and may change at any time. It will work if the same version of dnf is used to store and replay (or between versions as long as it stays the same).

-o <output-file>, --output=<output-file> Store the serialized transaction into <output-file>. Default is transaction.json.

```dnf history undo |````

Perform the opposite operation to all operations performed in the specified transaction. Uses the last transaction (with the highest ID) if more than one transaction for given <package-file-spec> is found. If it is not possible to undo some operations due to the current state of RPMDB, it will not undo the transaction.

dnf history userinstalled

Show all installonly packages, packages installed outside of DNF and packages not installed as dependency. I.e. it lists packages that will stay on the system when Autoremove Command or Remove Command along with clean_requirements_on_remove configuration option set to True is executed. Note the same results can be accomplished with dnf repoquery --userinstalled, and the repoquery command is more powerful in formatting of the output.

This command by default does not force a sync of expired metadata, except for the redo, rollback, and undo subcommands. See also Metadata Synchronization and Configuration Files Replacement Policy.

[AdamWill]

it seems like as of right now this is partially implemented, but not fully. notably:

[adamw@xps13a blivet (prefer-gpt-x86_64)]$ dnf history list ostree
Invalid transaction ID range "ostree", "ID" or "ID..ID" expected, where ID is "NUMBER", "last" or "last-NUMBER".
[adamw@xps13a blivet (prefer-gpt-x86_64)]$ 

i.e. you can't do history list (or, in fact, history info) by package name. It seems to only expect history transaction IDs. querying by package name is very useful and missing it is somewhat significant.

[kontura]

Make sure https://github.com/rpm-software-management/dnf/issues/2031 is fixed in the new rollback implementation.

[voxik]

Is there a chance to prioritize the undo / rollback functionality? I'd say this is in my experience the last missing bit to make the DNF5 fully usable for me.

[jan-kolarik]

Is there a chance to prioritize the undo / rollback functionality? I'd say this is in my experience the last missing bit to make the DNF5 fully usable for me.

After the completion of the system upgrade and related offline transactions (PoC already in review here), I'd say this currently stands as our second-highest priority issue. Given the significant overlap between the transactions store and replay functionality in the history command and the mentioned system-upgrade functionality, there shouldn't be an extensive amount of remaining work.

[retrixe]

Minor nit with the existing implementations of history info/undo/rollback in v5.2.5.0, numbers less than 1 e.g. 0 to specify the last transaction, -1 to specify the one before, etc, don't work (apologies if this is already known)