10:34 a.m.
Because (from what I understood, perhaps incorrectly) yum is going away in favor dnf, I
was trying to get used to the latter. Because the former is so ingrained in me, I was
trying to get rid of it from the system so that not having it available would force me to
think and thus get used to dnf.
So I try:
dnf erase yum
abrt x86_64 2.3.0-3.fc21 @System 1.9 M
abrt-addon-ccpp x86_64 2.3.0-3.fc21 @System 275 k
abrt-addon-kerneloops x86_64 2.3.0-3.fc21 @System 74 k
abrt-addon-pstoreoops x86_64 2.3.0-3.fc21 @System 14 k
abrt-addon-python x86_64 2.3.0-3.fc21 @System 19 k
abrt-addon-python3 x86_64 2.3.0-3.fc21 @System 14 k
abrt-addon-vmcore x86_64 2.3.0-3.fc21 @System 40 k
abrt-addon-xorg x86_64 2.3.0-3.fc21 @System 17 k
abrt-cli x86_64 2.3.0-3.fc21 @System 0
abrt-libs x86_64 2.3.0-3.fc21 @System 51 k
abrt-plugin-bodhi x86_64 2.3.0-3.fc21 @System 20 k
abrt-python x86_64 2.3.0-3.fc21 @System 57 k
abrt-python3 x86_64 2.3.0-3.fc21 @System 53 k
abrt-retrace-client x86_64 2.3.0-3.fc21 @System 105 k
abrt-tui x86_64 2.3.0-3.fc21 @System 24 k
anaconda-core x86_64 21.48.21-1.fc21 @System 7.7 M
anaconda-gui x86_64 21.48.21-1.fc21 @System 1.2 M
anaconda-tui x86_64 21.48.21-1.fc21 @System 373 k
anaconda-yum-plugins noarch 1:1.0-10.fc20 @System 21 k
createrepo noarch 0.10.3-3.fc21 @System 301 k
fedup noarch 0.9.0-2.fc21 @System 253 k
libreport x86_64 2.3.0-5.fc21 @System 1.8 M
libreport-anaconda x86_64 2.3.0-5.fc21 @System 15 k
libreport-cli x86_64 2.3.0-5.fc21 @System 29 k
libreport-fedora x86_64 2.3.0-5.fc21 @System 40 k
libreport-gtk x86_64 2.3.0-5.fc21 @System 219 k
libreport-plugin-bugzilla x86_64 2.3.0-5.fc21 @System 147 k
libreport-plugin-kerneloops x86_64 2.3.0-5.fc21 @System 37 k
libreport-plugin-logger x86_64 2.3.0-5.fc21 @System 35 k
libreport-plugin-reportuploader x86_64 2.3.0-5.fc21 @System 71 k
libreport-plugin-ureport x86_64 2.3.0-5.fc21 @System 55 k
libreport-python x86_64 2.3.0-5.fc21 @System 94 k
libreport-python3 x86_64 2.3.0-5.fc21 @System 41 k
libreport-web x86_64 2.3.0-5.fc21 @System 44 k
livecd-tools x86_64 1:21.4-1.fc21 @System 144 k
lorax x86_64 21.30-1.fc21 @System 440 k
python-imgcreate x86_64 1:21.4-1.fc21 @System 282 k
python-meh noarch 0.32-3.fc21 @System 251 k
python-meh-gui noarch 0.32-3.fc21 @System 24 k
yum noarch 3.4.3-153.fc21 @System 5.6 M
yum-langpacks noarch 0.4.4-1.fc21 @System 66 k
yum-plugin-fastestmirror noarch 1.1.31-27.fc21 @System 53 k
yum-plugin-remove-with-leaves noarch 1.1.31-27.fc21 @System 26 k
yum-utils noarch 1.1.31-27.fc21 @System 324 k
Question: why do stuff like createrepo, fedup, livecd-tools, etc still depend on yum?
Should they be made to depend on dnf now, in which case, should there be a bug report on
this?
Many thanks and best wishes,
Ranjan
--
Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt.
Please respond to the mailing list if appropriate. For those needing to send personal or
professional e-mail, please use appropriate addresses.
____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium
2:03 p.m.
On Mon, Dec 15, 2014 at 9:34 AM, Ranjan Maitra
<maitra.mbox.ignored(a)inbox.com> wrote:
Because (from what I understood, perhaps incorrectly) yum is going
away in favor dnf, I was trying to get used to the latter. Because the former is so
ingrained in me, I was trying to get rid of it from the system so that not having it
available would force me to think and thus get used to dnf.
So I try:
dnf erase yum
I suggest being really skeptical of dnf erase suggestions. It can be
brutal (don't try dnf erase kernel for example, it'll remove all
kernels including the running one). I also suggest being prepared to
file a bug in which case you need to use --debugsolver, e.g.
dnf --debugsolver upgrade
dnf --debugsolver erase blah
And then tar the resulting debug folder in the current directory and
attach to the bug. It's close to 100% chance you'll be asked for it so
you might as well just provide it from the start.
--
Chris Murphy
2:31 a.m.
On 15. 12. 2014 at 13:03:54, Chris Murphy wrote:
On Mon, Dec 15, 2014 at 9:34 AM, Ranjan Maitra
<maitra.mbox.ignored(a)inbox.com> wrote:
> Because (from what I understood, perhaps incorrectly) yum is going away in
> favor dnf, I was trying to get used to the latter. Because the former is
> so ingrained in me, I was trying to get rid of it from the system so that
> not having it available would force me to think and thus get used to dnf.
>
> So I try:
>
> dnf erase yum
I suggest being really skeptical of dnf erase suggestions. It can be
brutal (don't try dnf erase kernel for example, it'll remove all
kernels including the running one).
This is not true, the issue was fixed quite some time ago:
[root@boson ~]# dnf erase kernel
Dependencies resolved.
Error: The operation would result in removing the booted kernel:
kernel-3.17.4-200.fc20.x86_64.
I also suggest being prepared to
file a bug in which case you need to use --debugsolver, e.g.
dnf --debugsolver upgrade
dnf --debugsolver erase blah
And then tar the resulting debug folder in the current directory and
attach to the bug. It's close to 100% chance you'll be asked for it so
you might as well just provide it from the start.
This is definitely a good advice. Even though most of these issues are caused
by poor packaging of various Fedora rpms, it helps a lot to know what exactly
happened. See this page for more information on how to report a bug so it's as
helpful and descriptive as possible:
https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting
Thanks
Jan
4:08 p.m.
On 12/17/14 05:51, Lars E. Pettersson wrote:
On 12/16/14 22:32, Lars E. Pettersson wrote:
> Hm, could it be due to 'kernel' missing here?
Apparently not:
"Moreover, the currently booted kernel package is always protected."
(from
<http://rpm-software-management.github.io/dnf-plugins-core/protected_packa...>)
So, still strange that it wants to remove my running kernel...
I also noted that "dnf erase kernel deletes all packages called kernel" is
still on <http://dnf.readthedocs.org/en/latest/cli_vs_yum.html> :)
On the same page it says "No --skip-broken". I have used this quite often when
a single packages stops other packages from being updated. The example on the dnf vs. yum
page, "There is no equivalent for yum --skip-broken update foo, as silently skipping
foo in this case only amounts to masking an error contradicting the user request." is
missing the point of the --skip-broken switch, in my opinion. Or will dnf install all
updates except the one that is broken (in my use case)? (I have not tested dnf that much
to have experienced this myself)
bugzilla time seems in order?
--
If you can't laugh at yourself, others will gladly oblige.
3:32 p.m.
On 12/16/14 22:23, Lars E. Pettersson wrote:
Nah, still wants to remove the running kernel...
Hm, could it be due to 'kernel' missing here?
# ll /etc/{yum,dnf}/protected.d/*
-rw-r--r--. 1 root root 4 Dec 9 12:36 /etc/dnf/protected.d/dnf.conf
-rw-r--r--. 1 root root 8 Nov 27 15:07 /etc/yum/protected.d/systemd.conf
# cat /etc/{yum,dnf}/protected.d/*
systemd
dnf
#
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
3:23 p.m.
On 12/16/14 22:16, Rahul Sundaram wrote:
Upgrades to Fedora 22 should get it. I have added both dnf and the
core
plugin as default packages to the base group.
Good!
What I was suggesting is
to Lars is to install the plugin manually now and test whether that
explains the difference.
Nah, still wants to remove the running kernel...
# yum install dnf-plugins-core
...
Installing:
dnf-plugins-core noarch 0.1.4-1.fc21 updates
68 k
Installing for dependencies:
pykickstart noarch 1.99.63-2.fc21 fedora
323 k
...
# dnf erase kernel
...
Removing:
kernel x86_64 3.17.4-301.fc21 @System
0
kernel x86_64 3.17.4-302.fc21 @System
0
kernel x86_64 3.17.6-300.fc21 @System
0
...
# rpm -qa '*dnf*'|sort
dnf-0.6.3-2.fc21.noarch
dnf-plugins-core-0.1.4-1.fc21.noarch
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
2:24 a.m.
On 15. 12. 2014 at 17:23:48, Marko Vojinovic wrote:
On Mon, 15 Dec 2014 16:46:53 +0000
Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
> On Mon, 2014-12-15 at 10:34 -0600, Ranjan Maitra wrote:
> > Because (from what I understood, perhaps incorrectly) yum is going
> > away in favor dnf, I was trying to get used to the latter. Because
> > the former is so ingrained in me, I was trying to get rid of it
> > from the system so that not having it available would force me to
> > think and thus get used to dnf.
>
> Or you could alias yum to "echo Use DNF"
My understanding is that the name "dnf" is just a dummy placeholder,
so that --- once its code matures enough and the old yum code gets
obsolete --- "dnf" will simply be renamed to "yum", and its major
version number increased by a notch.
So the name "yum" isn't going anywhere, AFAIK.
Actually it's the exact opposite, dnf is going to continue being the project
name, as renaming it would cause nothing but pain. The discussion about the
name took place about a year ago on Fedora devel list if you are interested.
You can also find some explanation about the name here:
http://dnf.baseurl.org/2014/03/12/on-the-name/
Thanks
Jan
2:50 a.m.
On 15. 12. 2014 at 22:10:21, Sudhir Khanger wrote:
On Monday, December 15, 2014 10:34:30 AM Ranjan Maitra wrote:
> Question: why do stuff like createrepo, fedup, livecd-tools, etc still
> depend on yum? Should they be made to depend on dnf now, in which case,
> should there be a bug report on this?
Yum isn't going anywhere anytime soon. DNF doesn't support createrepo/local
repositories. Folks are going to use yum for at least a few releases even
after F22.
Well, yes and no. Yum is not going away completely but some powerful features
(like the extended dependency model) are coming to rpm which yum will not keep
up with and at that point it will pretty much stop working.
Thanks
Jan
10:40 a.m.
On Monday, December 15, 2014 10:34:30 AM Ranjan Maitra wrote:
Question: why do stuff like createrepo, fedup, livecd-tools, etc
still
depend on yum? Should they be made to depend on dnf now, in which case,
should there be a bug report on this?
Yum isn't going anywhere anytime soon. DNF doesn't support createrepo/local
repositories. Folks are going to use yum for at least a few releases even
after F22.
--
Regards,
Sudhir Khanger,
sudhirkhanger.com,
github.com/donniezazen,
5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394.
11:23 a.m.
On Mon, 15 Dec 2014 16:46:53 +0000
Patrick O'Callaghan <pocallaghan(a)gmail.com> wrote:
On Mon, 2014-12-15 at 10:34 -0600, Ranjan Maitra wrote:
> Because (from what I understood, perhaps incorrectly) yum is going
> away in favor dnf, I was trying to get used to the latter. Because
> the former is so ingrained in me, I was trying to get rid of it
> from the system so that not having it available would force me to
> think and thus get used to dnf.
Or you could alias yum to "echo Use DNF"
My understanding is that the name "dnf" is just a dummy placeholder,
so that --- once its code matures enough and the old yum code gets
obsolete --- "dnf" will simply be renamed to "yum", and its major
version number increased by a notch.
So the name "yum" isn't going anywhere, AFAIK.
Best, :-)
Marko
2:58 p.m.
On 12/16/14 21:53, Matthew Miller wrote:
There are some situations where it'd be nice to have DNF but the
plugin
behavior isn't necessary. So a hard dependency isn't ideal. And we
OK. That would mean that there are situations where the 'dnf erase
kernel' safeguard doesn't work either. Perhaps it would be better to
move this particular safeguard into dnf?
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
2:43 a.m.
On 15. 12. 2014 at 10:34:30, Ranjan Maitra wrote:
Because (from what I understood, perhaps incorrectly) yum is going
away in
favor dnf, I was trying to get used to the latter. Because the former is so
ingrained in me, I was trying to get rid of it from the system so that not
having it available would force me to think and thus get used to dnf.
So I try:
dnf erase yum
abrt x86_64 2.3.0-3.fc21 @System
1.9 M abrt-addon-ccpp x86_64 2.3.0-3.fc21
@System 275 k abrt-addon-kerneloops x86_64 2.3.0-3.fc21
@System 74 k abrt-addon-pstoreoops x86_64 2.3.0-3.fc21
@System 14 k abrt-addon-python x86_64
2.3.0-3.fc21 @System 19 k abrt-addon-python3
x86_64 2.3.0-3.fc21 @System 14 k abrt-addon-vmcore
x86_64 2.3.0-3.fc21 @System 40 k abrt-addon-xorg
x86_64 2.3.0-3.fc21 @System 17 k abrt-cli
x86_64 2.3.0-3.fc21 @System 0 abrt-libs
x86_64 2.3.0-3.fc21 @System 51 k abrt-plugin-bodhi
x86_64 2.3.0-3.fc21 @System 20 k abrt-python
x86_64 2.3.0-3.fc21 @System 57 k abrt-python3
x86_64 2.3.0-3.fc21 @System 53 k
abrt-retrace-client x86_64 2.3.0-3.fc21 @System
105 k abrt-tui x86_64 2.3.0-3.fc21
@System 24 k anaconda-core x86_64 21.48.21-1.fc21
@System 7.7 M anaconda-gui x86_64
21.48.21-1.fc21 @System 1.2 M anaconda-tui
x86_64 21.48.21-1.fc21 @System 373 k anaconda-yum-plugins
noarch 1:1.0-10.fc20 @System 21 k createrepo
noarch 0.10.3-3.fc21 @System 301 k fedup
noarch 0.9.0-2.fc21 @System 253 k libreport
x86_64 2.3.0-5.fc21 @System 1.8 M libreport-anaconda
x86_64 2.3.0-5.fc21 @System 15 k libreport-cli
x86_64 2.3.0-5.fc21 @System 29 k
libreport-fedora x86_64 2.3.0-5.fc21 @System
40 k libreport-gtk x86_64 2.3.0-5.fc21 @System
219 k libreport-plugin-bugzilla x86_64 2.3.0-5.fc21
@System 147 k libreport-plugin-kerneloops x86_64 2.3.0-5.fc21
@System 37 k libreport-plugin-logger x86_64 2.3.0-5.fc21
@System 35 k libreport-plugin-reportuploader x86_64
2.3.0-5.fc21 @System 71 k libreport-plugin-ureport
x86_64 2.3.0-5.fc21 @System 55 k libreport-python
x86_64 2.3.0-5.fc21 @System 94 k libreport-python3
x86_64 2.3.0-5.fc21 @System 41 k libreport-web
x86_64 2.3.0-5.fc21 @System 44 k livecd-tools
x86_64 1:21.4-1.fc21 @System 144 k lorax
x86_64 21.30-1.fc21 @System 440 k
python-imgcreate x86_64 1:21.4-1.fc21 @System
282 k python-meh noarch 0.32-3.fc21
@System 251 k python-meh-gui noarch 0.32-3.fc21
@System 24 k yum noarch
3.4.3-153.fc21 @System 5.6 M yum-langpacks
noarch 0.4.4-1.fc21 @System 66 k yum-plugin-fastestmirror
noarch 1.1.31-27.fc21 @System 53 k
yum-plugin-remove-with-leaves noarch 1.1.31-27.fc21 @System
26 k yum-utils noarch 1.1.31-27.fc21 @System
324 k
Question: why do stuff like createrepo, fedup, livecd-tools, etc still
depend on yum? Should they be made to depend on dnf now, in which case,
should there be a bug report on this?
We have already filed bugs to all those components that still rely on yum and
we hope people will port them soon. See the tracking bug [1] for details. We
continuously work on improving the documentation so people have some
examples to follow when porting their applications. We are also available on
#yum @ FreeNode to answer potential questions.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1156491
As for createrepo, that's a different topic. This project is going to die
alongside yum, as it shares some of the code base. At this point we are
working on createrepo_c. Written in C, it is ~30% more efficient and almost
feature complete when compared to the old createrepo (only deltas are missing
at this point but work in underway to change that).
Thanks
Jan
3:16 p.m.
Hi
On Tue, Dec 16, 2014 at 3:53 PM, Matthew Miller wrote:
On Tue, Dec 16, 2014 at 09:39:29PM +0100, Lars E. Pettersson wrote:
> > How come our systems behave differently?
> >Make sure you have dnf-plugins-core installed
> Shouldn't that package be a requirement of dnf, and due to that be
> installed automatically if dnf is installed?
There are some situations where it'd be nice to have DNF but the plugin
behavior isn't necessary. So a hard dependency isn't ideal. And we
don't have the details for soft dependencies all worked out. It does
seem like it should have been pulled in for an upgrade, one way or
another, though.
Upgrades to Fedora 22 should get it. I have added both dnf and the core
plugin as default packages to the base group. What I was suggesting is to
Lars is to install the plugin manually now and test whether that explains
the difference.
Rahul
3:51 p.m.
On 12/16/14 22:32, Lars E. Pettersson wrote:
Hm, could it be due to 'kernel' missing here?
Apparently not:
"Moreover, the currently booted kernel package is always protected."
(from
<http://rpm-software-management.github.io/dnf-plugins-core/protected_packa...>)
So, still strange that it wants to remove my running kernel...
I also noted that "dnf erase kernel deletes all packages called kernel"
is still on <http://dnf.readthedocs.org/en/latest/cli_vs_yum.html> :)
On the same page it says "No --skip-broken". I have used this quite
often when a single packages stops other packages from being updated.
The example on the dnf vs. yum page, "There is no equivalent for yum
--skip-broken update foo, as silently skipping foo in this case only
amounts to masking an error contradicting the user request." is missing
the point of the --skip-broken switch, in my opinion. Or will dnf
install all updates except the one that is broken (in my use case)? (I
have not tested dnf that much to have experienced this myself)
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
2:39 p.m.
On 12/16/14 21:34, Rahul Sundaram wrote:
On Tue, Dec 16, 2014 at 3:27 PM, Lars E. Pettersson wrote:
How come our systems behave differently?
Make sure you have dnf-plugins-core installed
Shouldn't that package be a requirement of dnf, and due to that be
installed automatically if dnf is installed?
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
5:31 p.m.
Hi
On Tue, Dec 16, 2014 at 4:51 PM, Lars E. Pettersson wrote:
On 12/16/14 22:32, Lars E. Pettersson wrote:
> Hm, could it be due to 'kernel' missing here?
>
Apparently not:
"Moreover, the currently booted kernel package is always protected."
(from <http://rpm-software-management.github.io/dnf-
plugins-core/protected_packages.html>)
So, still strange that it wants to remove my running kernel...
That would be good to file in a bug report.
I also noted that "dnf erase kernel deletes all packages called
kernel" is
still on <http://dnf.readthedocs.org/en/latest/cli_vs_yum.html>
Documentation bug
Or will dnf install all updates except the one that is broken (in my
use
case)? (I have not tested dnf that much to have experienced this myself)
Correct. dnf works as if you always pass -skip-broken. If you want it to
show the breakage for debugging, pass --best
Rahul
3:12 p.m.
On 12/16/2014 12:58 PM, Lars E. Pettersson wrote:
OK. That would mean that there are situations where the 'dnf erase
kernel' safeguard doesn't work either. Perhaps it would be better to
move this particular safeguard into dnf?
I know from experience that yum has that safeguard. (It came in very
handy when I moved this box to a PAE kernel because it was easier than a
complete reinstallation when I installed a new mobo with 8 GB RAM.) Not
having it in dnf would be a regression, so shifting that code from a
plugin to the main program would make sense.
2:53 p.m.
On Tue, Dec 16, 2014 at 09:39:29PM +0100, Lars E. Pettersson wrote:
> How come our systems behave differently?
>Make sure you have dnf-plugins-core installed
Shouldn't that package be a requirement of dnf, and due to that be
installed automatically if dnf is installed?
There are some situations where it'd be nice to have DNF but the plugin
behavior isn't necessary. So a hard dependency isn't ideal. And we
don't have the details for soft dependencies all worked out. It does
seem like it should have been pulled in for an upgrade, one way or
another, though.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:27 p.m.
On 12/16/14 09:31, Jan Zelený wrote:
On 15. 12. 2014 at 13:03:54, Chris Murphy wrote:
...
> I suggest being really skeptical of dnf erase suggestions. It can
be
> brutal (don't try dnf erase kernel for example, it'll remove all
> kernels including the running one).
This is not true, the issue was fixed quite some time ago:
On a system recently updated from f20 to f21:
# dnf erase kernel
...
Removing:
kernel x86_64 3.17.4-301.fc21 @System
0
kernel x86_64 3.17.4-302.fc21 @System
0
kernel x86_64 3.17.6-300.fc21 @System
0
...
# uname -a
Linux tux 3.17.6-300.fc21.x86_64 #1 SMP Mon Dec 8 22:29:32 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
[root@boson ~]# dnf erase kernel
Dependencies resolved.
Error: The operation would result in removing the booted kernel:
How come our systems behave differently?
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
10:46 a.m.
On Mon, 2014-12-15 at 10:34 -0600, Ranjan Maitra wrote:
Because (from what I understood, perhaps incorrectly) yum is going
away in favor dnf, I was trying to get used to the latter. Because the
former is so ingrained in me, I was trying to get rid of it from the
system so that not having it available would force me to think and
thus get used to dnf.
Or you could alias yum to "echo Use DNF"
poc
3455
days inactive
3456
days old
20 comments
11 participants
participants (11)
-
Chris Murphy -
Ed Greshko -
Jan Zelený -
Joe Zeff -
Lars E. Pettersson -
Marko Vojinovic -
Matthew Miller -
Patrick O'Callaghan -
Rahul Sundaram -
Ranjan Maitra -
Sudhir Khanger