Hello, thank you for the report. See this blog post: http://dnf.baseurl.org/2014/06/06/vote-for-yum-features-that-you-miss-in-dnf/

Please also note that there is an '--allowerasing' switch (see http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#packages-replacement-without-yum-shell). The more (real) (detailed) use cases not covered by this switch you provide the better for you.

No, I'm afraid you missunderstood me. The swap command allows to remove a package and install another package in one transaction. You could say its a shortcut for
  yum remove x && yum install y

Oh, yes, sure, sorry. OK, we'll see.

I kind of don't like that you can just remove something and install something in one transaction. What about other operations? But then it would be more like 'yum shell' (but in the form like 'python -c "cmd1;cmd2"'). So personally I don't like this command as I can't see the reason/use-case why this pair of operations has the privilege to be a standalone command. But that's just my opinion.

There are some situations where this is used. Most recently this command has been used to switch between fake and real systemd in Docker base images. However I was assured by Ales that the same thing is doable by dnf as it is, even though it's not called swap.

Heiko, could you please specify concrete reproducible situation where the --allowerasing switch doesn't work as you would expect? That's what the team needs to see. The point is not to implement something we thing users want but rather to address concrete problems. I'm afraid this will eventually get closed if there is no concrete and reproducible use case. Thanks

The swap command can be used also for two non-conflicting packages. That's the point I missed too.

*** Bug 1128358 has been marked as a duplicate of this bug. ***

Putting into needinfo per comment 4.

Possibly a dupe of bug 963137.

I am afraid that without this functionality, there is not possible to replace YUM by dnf-yum package:

$ sudo dnf install dnf-yum
Chyba: package dnf-yum-0.6.1-1.fc22.noarch conflicts with yum provided by yum-3.4.3-153.fc22.noarch


There is neither not supported "dnf shell", which would probably allow that.

Actually, the --allowerasing could probably achieve that, but it seems that prior that, mock and other packages should replace dependency on yum package by dependency on yum executable (if that is enough).

Jan, the last situation I can remember I used yum's swap command was replacing hexachat by polari. 

Or in general: the swap command is useful if you want to replace a package with another package providing a similar function but with no dependencies to package to be replaced.

I still don't see it:

If we want to swap package A for package B where the two don't conflict:

dnf install B && dnf erase A

That's what I believe exactly matches case described in comment 11.

If we want to swap package A for package B where B conflicts with A:

dnf --allowerasing install B

Reporter, can you provide a valid case, preferably with solver debug data [1], where one of the above operations don't suffice? Thanks!

[1] http://dnf.baseurl.org/2013/11/25/reporting-depsolving-bugs/

(In reply to Ales Kozumplik from comment #12)
> If we want to swap package A for package B where B conflicts with A:
> 
> dnf --allowerasing install B

Well, this works for my use case, thanks. Would it be possible to add a comment into dnf(8) man page that `swap`-like action is able to be done this way?

It might be better to have swap be an alias for --allow-erasing for compatibility.

(In reply to Rahul Sundaram from comment #14)
> It might be better to have swap be an alias for --allow-erasing for
> compatibility.

Dont do the same thing, --allow-erasing tells the solver it must remove installed packages to solve issues. So it is a more general purpose than just replaceing 1 package with another with the same provides.

yum swap is a shotcut for

yum shell
remove x 
install y
run

I know it doesn't do the same thing.  To avoid confusion, the end result I am looking for is that dnf swap foo bar actually be made to work preserving command line compatibility.

*** Bug 1149014 has been marked as a duplicate of this bug. ***

Another idea how to make things a bit better would be changing the help/man of dnf so it gives a clue to users searching for swap (include this word in the description), e.g.:

        --allowerasing
              Allow erasing of installed packages to resolve dependencies.
              In order to swap two packages run dnf install with --allowerasing.

I can mention it in man and cli vs yum differences and manual.

Is there any strong reasons NOT to support it in dnf?  It is widely used in yum in many scripts as well and having to change it all again to support dnf is a hassle.

Rahul, we don't need/want two commands for the same use case.

Well, that is a bit of circular logic.  You added something new and want to break compatibility with an existing command because you added something new.

The switch was introduced (as you might remember the bug 963137) with the hope that we can get rid of the "shell" command. Since the switch is already supported and it supports your use case, we don't need to add yet another command.

Before the new switch was introduced, I noted in that bug report that yum already supports a swap command and it would have been better to support it instead of introducing a new command.  This is what I am reiterating here.

To expand on that,  it doesn't particularly matter whether a new switch is being introduced to handle more use cases but yum swap is widely used.  This is not some edge corner case or undocumented option.  

https://www.google.com/search?q=yum+swap&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a&channel=sb

It is also not merely command line users but also configuration management systems and scripts that need to be changed.  For example, I am working on a patch to support dnf in a newly introduced script which uses yum swap and I have to add special conditions just because dnf doesn't support the same option. 

https://github.com/fedora-cloud/cloudtoserver/issues/4

Docker files use yum swap on a regular basis.  We have it being used in our Fedora wiki itself in many places.  Please don't break compatibility without very strong reasons to do so.

(In reply to Rahul Sundaram from comment #25)
> To expand on that,  it doesn't particularly matter whether a new switch is
> being introduced to handle more use cases but yum swap is widely used.  This
> is not some edge corner case or undocumented option.  

yum shell is also used a lot of places, but dnf dont support that
dnf != yum, one of idea by dnf was to clean things up and have more maintainable code base, all features is build about strong and sane usecases, an it was there in yum is not a strong usecase.
as the dnf developers already said, they dont add an extra cmd, when the feature to swap 2 packages allready exist.

Fedora is changing a lot of stuff all the time, so we have to learn new ways all the time.

Thank you bringing up yum shell.  That is a good example to compare and contrast.  yum shell is not used in scripts or configuration management or anywhere else other than interactively and is also a much more complex feature.

dnf may not be yum but calls itself yum4 in 

https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
 
Every change in the command line of a heavily used tool like yum or any successor to it adds a *substantial* burden to users and administrators.  I have already highlighted the very important "use case".  It is called compatibility.

From: https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF

For anybody using the command line directly there will be some differences, but all the important operations are available with DNF, using the same CLI syntax.

there can of course different views on what important operations are

Fedora has a long history of introducing new stuff there is not compatibility
with the old ones.

Ex. python2 -> python3, udisks -> udisk2, rules in PolycyKit (ini files to JS) etc.

If you are looking at the dnf python api it is totally different from yum, but dnf has a well documented public api, an yum has no api docs at all. All api consumers will have to rewrite there code, in this view the change from
using 'yum swap' to 'dnf install --allowerasing' seems like minor thing.

I have never used 'yum swap' and I dont see myself as a novice yum user, so I think that normal user dont use it very often or even know it exists.

You are setting up straw man arguments.  I never said Fedora cannot change.  I am saying, don't break compatibility in the command line without a strong justification for doing so.

As far the claim that yum swap is not popular, I welcome you to look at google search results and Fedora wiki.

Sorry, but I don't see any advantage in now doing 2 command line calls for a job yum does with 1 command line call.

So if you think you don't need/want a swap command, its okay to me because ATM I'm using Xfce which currently doesn't depend on dnf or hawkeye and which allows me to continue using yum.

(In reply to Heiko Adams from comment #30)
> Sorry, but I don't see any advantage in now doing 2 command line calls for a
> job yum does with 1 command line call.
> 

'dnf --allowerasing install foobar' is only one command

Reference of swap command from yum mentioned in "cli vs yum" and in dnf man page.

dnf-0.6.3-2.fc21,dnf-plugins-core-0.1.4-1.fc21,hawkey-0.5.2-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/dnf-0.6.3-2.fc21,dnf-plugins-core-0.1.4-1.fc21,hawkey-0.5.2-1.fc21

Package dnf-0.6.3-2.fc21, hawkey-0.5.2-1.fc21, dnf-plugins-core-0.1.4-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-0.6.3-2.fc21 hawkey-0.5.2-1.fc21 dnf-plugins-core-0.1.4-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-16760/dnf-0.6.3-2.fc21,dnf-plugins-core-0.1.4-1.fc21,hawkey-0.5.2-1.fc21
then log in and leave karma (feedback).

dnf-0.6.3-2.fc21, hawkey-0.5.2-1.fc21, dnf-plugins-core-0.1.4-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

I was just pointed at this *closed* bugreport from a maintainer ? developer ? ... Not really sure what his intentions was by doing so but reading through some comments here I am willing to back up the reasons brought up by Heiko Adams.

https://bugzilla.redhat.com/show_bug.cgi?id=963137#c17

Is there any reason to _not_ support dnf swap / yum swap with DNF?

See http://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/mess
age/5VBZ45TRTWNB7NAXW5HPYKZIUFMAW6HZ/ for a case where the --allowerasing workaround does not help.

Additionally

a) "install --allowerasing" is not particularly easy to find or even remember; I can't really think of anyone finding it any way _other_ than finding in the FAQ for "how do I do `yum swap` with dnf?", or reading a "secrets of DNF" article.

b) It worked fine in yum; why change the interface?

Could --allowerasing be extended to accept an operand?

Something like a wildcard and/or a list of packages allowed to be erased would work for me.  Allowing dnf to erase everything may result in unexpected decision to be made by dnf.

For inspiration, you can have a look at the option --remove-if-dependent which is offered by Paludis:

http://paludis.exherbo.org/clients/cave-resolve.html

Some other options (such as --permit-downgrade, --permit-old-version, --purge, or --uninstalls-may-break) may be also worth adding to dnf, but that is another story :-)

Otherwise, it is IMO good that it is implemented as a switch (instead of dnf command) because the switch could also be used for other commands than install.

(In reply to Matthew Miller from comment #37)
> Is there any reason to _not_ support dnf swap / yum swap with DNF?
> 
> See
> http://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
> mess
> age/5VBZ45TRTWNB7NAXW5HPYKZIUFMAW6HZ/ for a case where the --allowerasing
> workaround does not help.

Proper way to upgrade to new Fedora version is by using system-upgrade or distro-sync alternatively. In this case excluding (-x) broken packages is the easiest option.

> Additionally
> 
> a) "install --allowerasing" is not particularly easy to find or even
> remember; I can't really think of anyone finding it any way _other_ than
> finding in the FAQ for "how do I do `yum swap` with dnf?", or reading a
> "secrets of DNF" article.

In case there are some conflicts, DNF shows a hint about `--allowerasing` usage.

> b) It worked fine in yum; why change the interface?

Maybe we can support it in yum compatible layer or DNF itself.

(In reply to Kamil Dudka from comment #38)
> Could --allowerasing be extended to accept an operand?
> 
> Something like a wildcard and/or a list of packages allowed to be erased
> would work for me.  Allowing dnf to erase everything may result in
> unexpected decision to be made by dnf.

That's a good idea, Kamil. Libsolv already supports specifying concrete packages for removal. Protected packages should use this interface too to exclude protected packages from transaction removal beforehand not report just error afterwards.

> Some other options (such as --permit-downgrade, --permit-old-version,
> --purge, or --uninstalls-may-break) may be also worth adding to dnf, but
> that is another story :-)

downgrade is permitted when --allowerasing is set.

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

I know this is result of several poor packaging issues, but I faced this
recently and solved with `yum-deprecated shell` only..  even the `yum swap`
was not enough because I needed to swap two pairs of packages.

The issue (for the story, consider I've done this on production server,
but I still plan doing this in production):
I planned to switch from package 'foo-modified' to package 'foo', where
the package foo-modified is really  _poorly_ downstream-modified version
of 'foo' (no Obsoletes nor Collides tags), that means -> only *implicit*
file collisions between those two packages.  The 'foo-modified' is not
needed because Fedora's default 'foo' is already suitable for me, yay!

Steps I tried:
The `dnf install --allowerasing foo` calculated transaction (no issue
reported) and once I hit the 'Y' button, the execution of transaction
failed reporting file collisions (on RPM level).

Is there a way to replace *non-explicitly* colliding packages in dnf in
one transaction?  The --allowerasing doesn't help because there's nothing
obvious in the install transaction which _would make dnf think_ the
removal of `foo-modified` is needed.

I don't want to `dnf remove foo-modified && dnf install foo` because
remove might succeed and install *could* fail -> and that would cause
additional downtime... because system might be in inconsistent state (even
after re-installation of foo-modified).

(In reply to Pavel Raiskup from comment #41)
> (no Obsoletes nor Collides tags)

Sorry, s/Collides/Conflicts/.

Example:

    $ sudo dnf -y copr enable praiskup/bug-1110780-dnf-swap
    $ sudo dnf -y install foo-modified
    ...
    Complete!
    $ sudo dnf -y --allowerasing foo
    ...
    file /collides_here from install of foo-20161216_0044-0.fc25.x86_64 conflicts with file from package foo-modified-20161216_0044-0.fc25.x86_64
    ...

HOWTO 's/foo-modified/foo/' with dnf then?  This works (for now):

    $ sudo yum-deprecated -y swap foo-modified foo
    ...
    Complete!

Here is pull-request that add support of swap command: https://github.com/rpm-software-management/dnf/pull/679

Thanks for working on it.  FWIW, `dnf swap` is not enough, I actually
needed to have two `dnf swap` calls in once transaction (so I used `yum
shell` to resolve my issues).  Let me know if you want me to prepare
example (or if this deserves new ticket).

Hi Pavel,

DNF shell is also on the way - https://github.com/rpm-software-management/dnf/pull/658 .

Merged into the upstream: https://github.com/rpm-software-management/dnf/commit/7497d310df8390192e7bc1ccea9dc104ee3fc988

Bug fixed in version of dnf-2.0.1-1.