Bug 1311037

have you tried `dnf downgrade /tmp/sqlite-3.10.2.... --allowerasing`?

--allowerasing works now because there is an explicit conflict added in sqlite 3.11.0-2

package sqlite-libs-3.11.0-2.fc23.x86_64 conflicts with sqlite < 3.11.0-1 provided by sqlite-3.10.2-1.fc23.x86_64.

But not without this explicit conflicts

# LANG=C dnf downgrade /tmp/sqlite*3.10.2-1.fc23.x86_64.rpm --allowerasing
Dependencies resolved.
======================================================================================================================================================
 Package                              Arch                           Version                               Repository                            Size
======================================================================================================================================================
Downgrading:
 sqlite                               x86_64                         3.10.2-1.fc23                         @commandline                         475 k
 sqlite-devel                         x86_64                         3.10.2-1.fc23                         @commandline                         127 k
 sqlite-tcl                           x86_64                         3.10.2-1.fc23                         @commandline                          41 k

Transaction Summary
======================================================================================================================================================
Downgrade  3 Packages

Total size: 644 k
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction check error:
  file /usr/lib64/libsqlite3.so.0.8.6 from install of sqlite-3.10.2-1.fc23.x86_64 conflicts with file from package sqlite-libs-3.11.0-1.fc23.x86_64

Error Summary
-------------


So this bug is not about the specific sqlite issue (which have a workaround), but more to provide a use case of "yum shell", and why it is needed.

We are still reluctant to implement a yum shell equivalent. The main reason is that this functionality has been requested only by a negligible amount of DNF users so far. Anyway, I will keep this bug open for the tracking of interest.

I am interested in having a dnf shell as well.  Being able to explicitly describe the transaction you want to take place is extremely useful for troubleshooting.  As Remi pointed out above, unforeseen situations occur in packaging (both in base and third party repositories) that necessitate the power provided by a transaction shell.

I would also like to have something like yum shell for dnf.

I used to use yum shell in Dockerfiles. Now I can't.  This provides a more controlled use of dnf by only calling dnf once.

RUN dnf -y update && \
    dnf -y install git && \
    dnf clean all

vs

RUN printf "update
            install git
            run
            clean all" |
    dnf shell --assumeyes





Mentioning Docker counts like triple for this usecase right? (kidding)

I would like to add myself to the list of interested parties, much for the same reason Greg Swift brought up in Comment #6 around the Docker use case.

We are using yum shell with our automation systems as well as the docker use case. I would like to add my support for "yum shell" equivalent to dnf

I'm +1 to dnf shell.

(In reply to Adam Miller from comment #7)
> I would like to add myself to the list of interested parties, much for the
> same reason Greg Swift brought up in Comment #6 around the Docker use case.

+1 from me too

Asking around our support floor I found that one of the most common use cases was using shell to perform upgrades of various packages to newer 'major' versions, such as with IUS packages.

#yum shell
remove mysql-libs
install mysqlclient16
transaction solve
transaction run

and

#yum shell
remove php55u (other related packages)
install php56u (other related packages)
transaction solve
transaction run

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

We are still considering the implementation in DNF.

So far the gathered input from users shows that `yum shell` is popular and can do following what `--allowerasing` does not cover:
* less verbose task definition
* as temporary workaround (when packages not packaged properly, DNF does not correctly handle some use cases like kernel downgrade, etc.)

WRT comment 13 we have actually received very positive feedback about DNF dealing with IUS repository.

`dnf --allowerasing` is indeed quite handy for installing replacement IUS packages (php??u, mysql??u).  However, since that requires the incoming packages conflict with the outgoing packages, it does not work with IUS parallel-installable packages (python??u).

In any case, as useful as the allowerasing flag is, a transaction shell would provide more power, flexibility, and verbosity.

The shell command was implemented in dnf-2.1.0-1, that was released into rawhide.