Our Infrastructure depends on the swap command provided by yum. With Fedora 22 defaulting to dnf this (and other) features are missing. We require the option to remove a list of packages and install a list of new packages "in place". Simple example: yum remove gnome-desktop will remove a lot of packages (let's assume 1000) yum install xfce-desktop will install a lot of packages (let's assume 700) installing the packages that has previously been removed with "remove" yum swap -- autoremove gnome-desktop -- install xfce4-desktop runs through the process of resolving the requirments of remove as much as needed from gnome-desktop and installing as much as needed from xfce4-desktop without the requirement to remove everything, that gets installed afterwards again. This was just an example! I don't see how to achieve this task once we switch to Fedora 22. Needless to mention that our infrastructure relies on this.
Hello, actually this Bugzilla instance already contains a report with almost the same summary (and a nice flame inside) :-) Also this page could help you: http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#packages-replacement-without-yum-shell-or-yum-swap Anyway, try "dnf --allowerasing install xfce4-desktop" and if it doesn't work, let us know. *** This bug has been marked as a duplicate of bug 963137 ***
The above command set was just an example. More precisely we like to substitute a set of packages A by a set of packages B I still don't understand how --allowerasing knows what packages A we like to replace with packages B ? The example above is surely quite easy to understand: yum swap -- autoremove gnome-desktop -- install xfce-desktop That's clearly to understand. dnf --allowerasing install xfce-desktop Is understandable by me as well. For me it says: Install xfce-desktop and remove all the other cruft that is not required by it. Some sort of "replace it". But what if I only want to have a subset of packages A replaced with a subset of packages B. I don't see how to do this with dnf. I must admit, that I haven't tried it, but from the theoretical logic - I don't get it. This is needlessly complicated that way. More precisely the part of the code we have looks like this: # fkt_package_swap fkt_package_swap() { yum swap --assumeyes \ --installroot="${instroot}" \ --disablerepo="${rpmrepo1}" \ --enablerepo="${rpmrepo2}" \ --noplugins \ --nogpgcheck \ \ -- autoremove ${package2} \ -- install ${package3} } package2: is an external txt file containing different packages we like to remove package3: is an external txt file containing different packages we like to install Swap resolves unnecessary removes and reinstalls. So please how can I ahieve the same by using dnf ?
I cannot find xfce-desktop. Do you mean @xfce-desktop or xfdesktop? Anyway, I assumed that these packages/groups conflict because AFAIK this is the purpose of "yum swap" - to replace one package by another one without an intermediate replacement of their common dependencies - but the opposite is true, they can be safely installed together. So, the solution is simply: dnf <your-switches> install ${package3} dnf <your-switches> remove ${package2} Is the only problem with the above that it may be a bit slower than "yum swap"? Or do I still miss something?
(In reply to Radek Holy from comment #3) > So, the solution is simply: > dnf <your-switches> install ${package3} > dnf <your-switches> remove ${package2} I am sorry but this is wrong. This is an approach how this can be handled. But this is not what "yum swap" does. Theoretical example: Package 1 ...: mxterm.rpm Dependency 1.: motif.rpm <-- Dependency 2.: popt.rpm Package 2 ...: nedit.rpm Dependency 1.: motif.rpm <-- Dependency 2.: icons.rpm Usin yum: yum autoremove mxterm.rpm *) will remove mxterm.rpm and remove motif.rpm and popt.rpm yum install nedit.rpm *) will install nedit.rpm and motif.rpm and icons.rpm Problem: It removes motif.rpm (which was installed before) and installs motif.rpm once again. yum swap -- autoremove mxterm.rpm --install nedit.rpm *) will remove mxterm.rpm and icons.rpm the package motif.rpm will be kept because we like to install nedit.rpm With my above example I hand a list of say 500 packages over to ${package2} which we like to remove and a list of say 200 packages over to ${package3} which we like to install. yum swap will internally resolve the dependency of the removed package... but resolves the packages of the to be installed packages in ONE go. With other words: yum resolves the removed packages and all its dependencies (autoremove) but also resolves the depdendencies of all packages to be installed. It then - from my personal experiences since I've been using it - also checks which packages of the dependencies that got marked for deinstallation is required by the installation and thus drop the mark for deinstallation (because it's required by the packages that gets installed). What you suggest here works but is not the desired effect we like to have. We don't want to have dependencies deinstalled and then re-installed afterwards. Swap simply skips them from being deinstalled. Sidenote: On Fedora 20 (the system we like to change to Fedora 22 soon) we do have the meta package "xfce-desktop" sudo yum group install xfce-desktop exists. Copied out of the *comps-f20.xml package found in the /cache/yum/i386/20/fedora/*-comps-f20.xml file. <group> <id>xfce-desktop</id> <name>Xfce</name> <name xml:lang="as">Xfce</name> <name xml:lang="bg">Xfce</name> ... </group>
I think you might have misunderstood. What Radek proposes will not uninstall the dependencies and install them again. He proposed running install first and remove afterwards, not the other way around.
The same infrastructure is also used to pull Fedora Rawhide :) which has the same entry in the comp-rawhide.xml file found in the rawhide cache dir. A note: Above I wrote that your approach may works as well (the sentence continues with .... is not what we desire)... This is not entirely true. There was a time where yum didn't had the swap feature either ... If I hand over a set of 500 packages to be autoremoved in one go, then you know what will happen. The internal process resolving dependencies will probably end up removing the entire distribution or end up with an error message saying that either yum, systemd, some other tools are protected from being deleted. That's because of the entire rats tail of one package depending to another. In above example it's safe to remove mxterm.rpm for example... but removing motif.rpm will probably end up marking the entire rats tail down for deinstallation. This can happen... must not... The swap feature leaves motif.rpm untouched because we chirurgically cut out a subset of packs and replace them with another subset of packs. Not going down the entire rats tail. Which can happen as well... must not... I hope I could explain the situation and and case here. You may understand, why I was scared for a day after I heard that yum now redirects to dnf and yum-deprecated spits out "this software is deprecated" messages. I am all for dnf and I am willing to support and help testing it. But I am scared what to tell a customer if he/she reads "yum is deprecated" once we introduce our infrastructure. It would look like we don't know our business...
(In reply to Jan Zeleny from comment #5) > I think you might have misunderstood. What Radek proposes will not uninstall > the dependencies and install them again. He proposed running install first > and remove afterwards, not the other way around. Oh sorry I've missed that. Of course I will test this and report back.