Red Hat Bugzilla – Bug 1311037
RFE: implement yum shell
Last modified: 2017-03-14 05:42:43 EDT
Related to #1311032
Because of the split of sqlite into a new sqlite-libs, no way to downgrade
$ yum shell
> remove sqlite-libs
> downgrade /tmp/sqlite-3.10.2....
How to do the same with DNF ?
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
Package Arch Version Repository Size
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
Downgrade 3 Packages
Total size: 644 k
Is this ok [y/N]: y
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
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
RUN printf "update
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.
remove php55u (other related packages)
install php56u (other related packages)
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.