Hello,
On behalf of the DNF team I'd like to invite all the interested Fedora users in trying out and testing DNF in Fedora 20. DNF is a tool that aims to fully replace Yum by Fedora 22. Please check out the blog post for more information:
http://dnf.baseurl.org/2013/12/19/dnf-and-fedora-20/
We look forward to hear your feedback and kindly ask you to use bugzilla to report any issues found.
Thank you,
Ales Kozumplik, DNF project lead
On 12/20/2013 12:33 PM, Ales Kozumplik wrote:
On behalf of the DNF team I'd like to invite all the interested Fedora users in trying out and testing DNF in Fedora 20. DNF is a tool that aims to fully replace Yum by Fedora 22. Please check out the blog post for more information:
A question, I found the following on http://akozumpl.github.io/dnf/cli_vs_yum.html
"dnf erase kernel deletes all packages called kernel
In Yum, the running kernel is spared. There is no reason to keep this in DNF, the user can always specify concrete versions on the command line, e.g.:
dnf erase kernel-3.9.4"
So if I issue 'dnf erase kernel' all kernels will be removed, and I have no kernel anymore? Is that really a good thing? Should we not spare the running kernel? Or is there some rationale behind this that I am missing?
Lars
On Fri, Dec 20, 2013 at 12:33:18PM +0100, Ales Kozumplik wrote:
Hello,
On behalf of the DNF team I'd like to invite all the interested Fedora users in trying out and testing DNF in Fedora 20. DNF is a tool that aims to fully replace Yum by Fedora 22. Please check out the blog post for more information:
http://dnf.baseurl.org/2013/12/19/dnf-and-fedora-20/
We look forward to hear your feedback and kindly ask you to use bugzilla to report any issues found.
I have been using this since F20 release. I noticed there is no completion available, unlike yum. I can probably reuse yum's completion with dnf by simply `complete -F _yum dnf', but I'm afraid that will be unaware of the subtle differences between yum and dnf. Is that a valid worry, or can I blindly reuse _yum?
Cheers,
HI
On Wed, Jan 1, 2014 at 6:27 PM, Suvayu Ali wrote:
I have been using this since F20 release. I noticed there is no completion available, unlike yum. I can probably reuse yum's completion with dnf by simply `complete -F _yum dnf', but I'm afraid that will be unaware of the subtle differences between yum and dnf. Is that a valid worry, or can I blindly reuse _yum?
Ideally, you should file it as an RFE in bugzilla. Although dnf and yum are broadly compatible, there are subtle differences that will trip you up otherwise.
Rahul
On 2 January 2014 02:07, Rahul Sundaram metherid@gmail.com wrote:
HI
On Wed, Jan 1, 2014 at 6:27 PM, Suvayu Ali wrote:
I have been using this since F20 release. I noticed there is no completion available, unlike yum. I can probably reuse yum's completion with dnf by simply `complete -F _yum dnf', but I'm afraid that will be unaware of the subtle differences between yum and dnf. Is that a valid worry, or can I blindly reuse _yum?
Ideally, you should file it as an RFE in bugzilla. Although dnf and yum are broadly compatible, there are subtle differences that will trip you up otherwise.
Rahul
https://bugzilla.redhat.com/show_bug.cgi?id=1030440
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 01/01/2014 11:13 PM, Lars E. Pettersson wrote:
On 12/20/2013 12:33 PM, Ales Kozumplik wrote:
On behalf of the DNF team I'd like to invite all the interested Fedora users in trying out and testing DNF in Fedora 20. DNF is a tool that aims to fully replace Yum by Fedora 22. Please check out the blog post for more information:
A question, I found the following on http://akozumpl.github.io/dnf/cli_vs_yum.html
"dnf erase kernel deletes all packages called kernel
In Yum, the running kernel is spared. There is no reason to keep this in DNF, the user can always specify concrete versions on the command line, e.g.:
dnf erase kernel-3.9.4"
So if I issue 'dnf erase kernel' all kernels will be removed, and I have no kernel anymore?
Apparently, this is what dnf does:
# dnf remove kernel Resolving dependencies --> Starting dependency resolution --> Finding unneeded leftover dependencies ... ---> Package kernel.x86_64 3.11.10-301.fc20 will be erased ---> Package kernel.x86_64 3.12.5-302.fc20 will be erased ---> Package kmod-nvidia.x86_64 1:331.20-10.fc20.1 will be erased ---> Package kmod-nvidia-3.11.10-301.fc20.x86_64.x86_64 1:331.20-10.fc20 will be erased ---> Package kmod-nvidia-3.12.5-302.fc20.x86_64.x86_64 1:331.20-10.fc20.1 will be erased ...
Is that really a good thing?
IMO, this behavior is inacceptable and disqualifies dnf from being made distribution-wide default.
Should we not spare the running kernel?
If you look closer, yum doesn't only spare the running kernel, but allows a configurable number of multiple versions of some packages (notably: kernels and kernel-modules).
The rationale for this is keeping fallback-kernels on the system in case a kernel update does not boot or is mal-functioning.
Or is there some rationale behind this that I am missing?
I think the dnf developers' are missing an important piece of yum history.
Ralf
On Fri, 20 Dec 2013 12:33:18 +0100 Ales Kozumplik akozumpl@redhat.com wrote:
We look forward to hear your feedback and kindly ask you to use bugzilla to report any issues found.
How does it handle yum plugins?, I use yum (updateonboot) --security on all daily reboot boxes. # + all other boxes
Can I get it to use existing yum-cache (nfs shared among boxes)
Just some thoughts man dnf hasn't shed light for me ___
Regards, Frank www.frankly3d.com
On 01/02/2014 11:45 AM, Frank Murphy wrote:
On Fri, 20 Dec 2013 12:33:18 +0100 Ales Kozumplik akozumpl@redhat.com wrote:
We look forward to hear your feedback and kindly ask you to use bugzilla to report any issues found.
How does it handle yum plugins?, I use yum (updateonboot) --security on all daily reboot boxes. # + all other boxes
Hi Frank,
we won't support Yum plugins directly but will support a plugin mechanism and will actively help with porting the plugins. If there are specific plugins you'd like to see sooner please open bugs for them.
Thanks, Ales
A question, I found the following on http://akozumpl.github.io/dnf/cli_vs_yum.html
"dnf erase kernel deletes all packages called kernel
In Yum, the running kernel is spared. There is no reason to keep this in DNF, the user can always specify concrete versions on the command line, e.g.:
dnf erase kernel-3.9.4"
So if I issue 'dnf erase kernel' all kernels will be removed, and I have no kernel anymore? Is that really a good thing? Should we not spare the running kernel? Or is there some rationale behind this that I am missing?
Lars
Hi Lars,
yes that's the idea. In practice however, a user doesn't type 'dnf erase -y kernel' by accident and we don't feel the need to protect users who really know what they are doing from doing so. It's the same situation as 'rm -rf /boot' or 'rpm -e --allmatches kernel'. Of course, people are welcome to write specific plugins to achieve something similar to what Yum used to do.
Ales
On Thu, 02 Jan 2014 11:50:56 +0100 Ales Kozumplik akozumpl@redhat.com wrote:
we won't support Yum plugins directly but will support a plugin mechanism and will actively help with porting the plugins. If there are specific plugins you'd like to see sooner please open bugs for them.
Thanks, Ales
Can I ln -s /path/to/yum-cache /path/to/dnf-cache ? Is dnf cache-structure similar enough (not having a spare to test currently, virt-server' down)
___ Regards, Frank www.frankly3d.com
On 01/02/2014 11:54 AM, Ales Kozumplik wrote:
A question, I found the following on http://akozumpl.github.io/dnf/cli_vs_yum.html
"dnf erase kernel deletes all packages called kernel
In Yum, the running kernel is spared. There is no reason to keep this in DNF, the user can always specify concrete versions on the command line, e.g.:
dnf erase kernel-3.9.4"
So if I issue 'dnf erase kernel' all kernels will be removed, and I have no kernel anymore? Is that really a good thing? Should we not spare the running kernel? Or is there some rationale behind this that I am missing?
Lars
Hi Lars,
yes that's the idea. In practice however, a user doesn't type 'dnf erase -y kernel' by accident and we don't feel the need to protect users who really know what they are doing from doing so.
IMO, you are plain wrong.
You've never used scripts similar to sth. like this: rpm -qa ... | grep ... | yum remove -y and never encountered bugs with such scripts?
IIRC, debian's apt even has blacklists (protected packages) to prevent critical damages.
It's the same situation as 'rm -rf /boot' or 'rpm -e --allmatches kernel'.
No. It is not. Think about non-bootable/broken kernels etc.
The kernel is a master piece of a package which must be allowed to be installed in multiple instances and of which at least the running instance must not be removed under any circumstances.
Of course, people are welcome to write specific plugins to achieve something similar to what Yum used to do.
You don't really want to know what I think about this - It really pisses me off. You are trying to defend a behavioral regression *you* are reponsible for onto users.
Ralf
On 01/02/2014 11:58 AM, Frank Murphy wrote:
On Thu, 02 Jan 2014 11:50:56 +0100 Ales Kozumplik akozumpl@redhat.com wrote:
we won't support Yum plugins directly but will support a plugin mechanism and will actively help with porting the plugins. If there are specific plugins you'd like to see sooner please open bugs for them.
Thanks, Ales
Can I ln -s /path/to/yum-cache /path/to/dnf-cache ? Is dnf cache-structure similar enough (not having a spare to test currently, virt-server' down)
I have to say we don't support this and it could break both yum and DNF.
Ales
On 01/02/2014 12:13 PM, Ralf Corsepius wrote:
The kernel is a master piece of a package which must be allowed to be installed in multiple instances and of which at least the running instance must not be removed under any circumstances.
Thanks Ralf. Just to clarify: DNF supports multiple kernels installed in parallel, nothing changed there.
Ales
On Thu, Jan 2, 2014 at 10:54 AM, Ales Kozumplik akozumpl@redhat.com wrote:
yes that's the idea. In practice however, a user doesn't type 'dnf erase -y kernel' by accident and we don't feel the need to protect users who really know what they are doing from doing so. It's the same situation as 'rm -rf /boot' or 'rpm -e --allmatches kernel'. Of course, people are welcome to write specific plugins to achieve something similar to what Yum used to do.
Lots of users think they know what they're doing when in fact they don't and are just trying things out. While I'm against excessive hand-holding in general, removing what might be the only installed kernel is a really bad way to teach them a lesson.
poc
On 01/02/2014 11:54 AM, Ales Kozumplik wrote:
yes that's the idea. In practice however, a user doesn't type 'dnf erase -y kernel' by accident and we don't feel the need to protect users who really know what they are doing from doing so.
I would urge you to reconsider this given the importance of the kernel.
Lars
On Thu, Jan 02, 2014 at 12:01:09PM +0000, Patrick O'Callaghan wrote:
On Thu, Jan 2, 2014 at 10:54 AM, Ales Kozumplik akozumpl@redhat.com wrote:
yes that's the idea. In practice however, a user doesn't type 'dnf erase -y kernel' by accident and we don't feel the need to protect users who really know what they are doing from doing so. It's the same situation as 'rm -rf /boot' or 'rpm -e --allmatches kernel'. Of course, people are welcome to write specific plugins to achieve something similar to what Yum used to do.
Lots of users think they know what they're doing when in fact they don't and are just trying things out. While I'm against excessive hand-holding in general, removing what might be the only installed kernel is a really bad way to teach them a lesson.
Is there any scenario where removing all kernels would make sense?
On Thu, 2 Jan 2014 13:15:22 +0100 Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
Is there any scenario where removing all kernels would make sense?
writing malware :)
___ Regards, Frank www.frankly3d.com
Ales Kozumplik wrote:
On behalf of the DNF team I'd like to invite all the interested Fedora users in trying out and testing DNF in Fedora 20. DNF is a tool that aims to fully replace Yum by Fedora 22.
Yum works perfectly well, in my experience. The problems you discuss are never met by the average user (like me), who simply use "yum update" and "yum install".
By all means introduce an alternative, but please leave yum for those who are satisfied with it. Not another grub2, please.
On 2. 1. 2014 at 13:32:23, Timothy Murphy wrote:
Ales Kozumplik wrote:
On behalf of the DNF team I'd like to invite all the interested Fedora users in trying out and testing DNF in Fedora 20. DNF is a tool that aims to fully replace Yum by Fedora 22.
Yum works perfectly well, in my experience. The problems you discuss are never met by the average user (like me), who simply use "yum update" and "yum install".
By all means introduce an alternative, but please leave yum for those who are satisfied with it. Not another grub2, please.
It's actually going to be the other way around - yum will be an alternative to dnf. The thing is that yum will soon enter maintenance mode - most of the planned new features will happen in dnf, not in yum.
At this point I will repeat that dnf is based on the original yum code so for vast majority of users the change will not be noticeable and everything will continue to work the same.
Thanks Jan
On 02.01.2014 12:13, Ralf Corsepius wrote:
On 01/02/2014 11:54 AM, Ales Kozumplik wrote:
A question, I found the following on http://akozumpl.github.io/dnf/cli_vs_yum.html
"dnf erase kernel deletes all packages called kernel
In Yum, the running kernel is spared. There is no reason to keep this in DNF, the user can always specify concrete versions on the command line, e.g.:
dnf erase kernel-3.9.4"
So if I issue 'dnf erase kernel' all kernels will be removed, and I have no kernel anymore? Is that really a good thing? Should we not spare the running kernel? Or is there some rationale behind this that I am missing?
Lars
Hi Lars,
yes that's the idea. In practice however, a user doesn't type 'dnf erase -y kernel' by accident and we don't feel the need to protect users who really know what they are doing from doing so.
IMO, you are plain wrong.
You've never used scripts similar to sth. like this: rpm -qa ... | grep ... | yum remove -y and never encountered bugs with such scripts?
IIRC, debian's apt even has blacklists (protected packages) to prevent critical damages.
It's the same situation as 'rm -rf /boot' or 'rpm -e --allmatches kernel'.
No. It is not. Think about non-bootable/broken kernels etc.
The kernel is a master piece of a package which must be allowed to be installed in multiple instances and of which at least the running instance must not be removed under any circumstances.
Of course, people are welcome to write specific plugins to achieve something similar to what Yum used to do.
You don't really want to know what I think about this - It really pisses me off. You are trying to defend a behavioral regression *you* are reponsible for onto users.
Did Not Finish Do Not Forget Does Not Follow Data Not Found Did Not Find Does Not Function Do Not Freeze Do Not Fix Do Not Fax Do Not Forward
Fully functional DNF is expected within Fedora XXX, A.D. MMXIX. Let's be patient!
poma
On 01/02/2014 02:01 PM, Jan Zelený wrote:
On 2. 1. 2014 at 13:32:23, Timothy Murphy wrote:
Ales Kozumplik wrote:
On behalf of the DNF team I'd like to invite all the interested Fedora users in trying out and testing DNF in Fedora 20. DNF is a tool that aims to fully replace Yum by Fedora 22.
Yum works perfectly well, in my experience. The problems you discuss are never met by the average user (like me), who simply use "yum update" and "yum install".
By all means introduce an alternative, but please leave yum for those who are satisfied with it. Not another grub2, please.
It's actually going to be the other way around - yum will be an alternative to dnf. The thing is that yum will soon enter maintenance mode
Says who and has decided who?
If Fedora was an openly lead project, a yum competitor such as dnf would be evaluated against yum and a decision be drawn at an arbitrary future point in time.
Ralf
On 02/01/14 18:10, poma wrote:
On 02.01.2014 12:13, Ralf Corsepius wrote:
On 01/02/2014 11:54 AM, Ales Kozumplik wrote:
A question, I found the following on http://akozumpl.github.io/dnf/cli_vs_yum.html
"dnf erase kernel deletes all packages called kernel
In Yum, the running kernel is spared. There is no reason to keep this in DNF, the user can always specify concrete versions on the command line, e.g.:
dnf erase kernel-3.9.4"
So if I issue 'dnf erase kernel' all kernels will be removed, and I have no kernel anymore? Is that really a good thing? Should we not spare the running kernel? Or is there some rationale behind this that I am missing?
Lars
Hi Lars,
yes that's the idea. In practice however, a user doesn't type 'dnf erase -y kernel' by accident and we don't feel the need to protect users who really know what they are doing from doing so.
IMO, you are plain wrong.
You've never used scripts similar to sth. like this: rpm -qa ... | grep ... | yum remove -y and never encountered bugs with such scripts?
IIRC, debian's apt even has blacklists (protected packages) to prevent critical damages.
It's the same situation as 'rm -rf /boot' or 'rpm -e --allmatches kernel'.
No. It is not. Think about non-bootable/broken kernels etc.
The kernel is a master piece of a package which must be allowed to be installed in multiple instances and of which at least the running instance must not be removed under any circumstances.
Of course, people are welcome to write specific plugins to achieve something similar to what Yum used to do.
You don't really want to know what I think about this - It really pisses me off. You are trying to defend a behavioral regression *you* are reponsible for onto users.
Did Not Finish Do Not Forget Does Not Follow Data Not Found Did Not Find Does Not Function Do Not Freeze Do Not Fix Do Not Fax Do Not Forward
Fully functional DNF is expected within Fedora XXX, A.D. MMXIX. Let's be patient!
I do believe Fedora XXX slips into A.D. MMXX. Be more patient
On Thu, 2014-01-02 at 19:15 +0100, Ralf Corsepius wrote:
Says who and has decided who?
If Fedora was an openly lead project, a yum competitor such as dnf would be evaluated against yum and a decision be drawn at an arbitrary future point in time.
This is the first I've heard of dnf, however a cursory Google search shows that it has been discussed for months. I presume that were I involved in the forums and mailing lists where the future of Fedora was being discussed, I would have had ample opportunity to do just what you are talking about. Since I have chosen not to be actively involved in the Fedora development process, I am not shocked by development decisions getting made without my input.
Woogie
On Thu, Jan 2, 2014 at 1:01 PM, Jan Zelený jzeleny@redhat.com wrote:
At this point I will repeat that dnf is based on the original yum code so for vast majority of users the change will not be noticeable and everything will continue to work the same.
That would imply that someone actually took the decision to *remove* the protections against leaving the system with no installed kernel. Was this discussed? What were the proposers smoking?
poc
On Jan 2, 2014, at 4:42 PM, "Patrick O'Callaghan" pocallaghan@gmail.com wrote:
On Thu, Jan 2, 2014 at 1:01 PM, Jan Zelený jzeleny@redhat.com wrote: At this point I will repeat that dnf is based on the original yum code so for vast majority of users the change will not be noticeable and everything will continue to work the same.
That would imply that someone actually took the decision to *remove* the protections against leaving the system with no installed kernel. Was this discussed? What were the proposers smoking?
Keep in mind the context is the vast majority. The majority doesn't manually remove kernels, this is done for them and it only removes the oldest, and one at a time per additional install.
An open question that I think is valid is if dnf remove kernel also removes the rescue kernel/initramfs, or if it just removes packaged kernels. I suspect the rescue initramfs is still intact which means we ought to still have the ability to rescue the system if indeed all kernels are removed.
I've been using dnf for over a year and other than some bugs that were relatively quickly fixed it's been identical to the most common yum use cases except it's a lot faster.
Chris Murphy
On 01/02/2014 03:42 PM, Patrick O'Callaghan wrote:
That would imply that someone actually took the decision to *remove* the protections against leaving the system with no installed kernel. Was this discussed? What were the proposers smoking?
It's always been a principle that *nix won't stop you from doing something stupid if it prevents me from doing something clever. I can't see how removing the installed kernel could be clever, but that might have been behind their thinking.
Actually, AIUI, the file isn't removed until the last program that's using it closes the file. Now, I can't swear to it, but it's reasonable to think that the kernel keeps its file open so that parts of it can come in and out of memory as needed, although that may not be true any more because of how much RAM most machines have. Even so, uninstalling the running kernel won't do anything about the copy that's actually doing the work, because that's in RAM so as long as you remember to install at least one kernel before rebooting, you should be safe. What happens if your system crashes, or there's a power failure before that happens is best left as an exercise for the reader.
I'm not saying that I think this is the way dnf should work, but it's possible that this is how the devs were thinking.
Hi.
I'm not a power user of yum.
I''ve never used dnf, didn't even know it existed until a few days ago via this thread.
And I don't mean this to be a dig at the dev team of the app/function.
However, given some of the points made in this thread, I'm wondering if the devs of this app have created/posted/made available for others to take a look at, the overall Use Cases for the app.
This map would go a long way towards letting people get a good feel for what yum used to do, what dnf will do, and where potential holes may/may not exist.
At the same time, being able to post real world test case scenarios would strengthen the case for dnf to take over from dnf.
Again, I'm not a guy with any dog in this hunt, just a guy who's been building software for 25+ years!!
Have fun!
On Thu, Jan 2, 2014 at 7:00 PM, Chris Murphy lists@colorremedies.com wrote:
On Jan 2, 2014, at 4:42 PM, "Patrick O'Callaghan" pocallaghan@gmail.com wrote:
On Thu, Jan 2, 2014 at 1:01 PM, Jan Zelený jzeleny@redhat.com wrote:
At this point I will repeat that dnf is based on the original yum code so for vast majority of users the change will not be noticeable and everything will continue to work the same.
That would imply that someone actually took the decision to *remove* the protections against leaving the system with no installed kernel. Was this discussed? What were the proposers smoking?
Keep in mind the context is the vast majority. The majority doesn't manually remove kernels, this is done for them and it only removes the oldest, and one at a time per additional install.
An open question that I think is valid is if dnf remove kernel also removes the rescue kernel/initramfs, or if it just removes packaged kernels. I suspect the rescue initramfs is still intact which means we ought to still have the ability to rescue the system if indeed all kernels are removed.
I've been using dnf for over a year and other than some bugs that were relatively quickly fixed it's been identical to the most common yum use cases except it's a lot faster.
Chris Murphy
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 01/02/2014 12:54 PM, Ales Kozumplik wrote:
A question, I found the following on http://akozumpl.github.io/dnf/cli_vs_yum.html
"dnf erase kernel deletes all packages called kernel
In Yum, the running kernel is spared. There is no reason to keep this in DNF, the user can always specify concrete versions on the command line, e.g.:
dnf erase kernel-3.9.4"
So if I issue 'dnf erase kernel' all kernels will be removed, and I have no kernel anymore? Is that really a good thing? Should we not spare the running kernel? Or is there some rationale behind this that I am missing?
Lars
Hi Lars,
yes that's the idea. In practice however, a user doesn't type 'dnf erase -y kernel' by accident and we don't feel the need to protect users who
Just in case it happens, is it possible to prepare in advance a wiki page with instructions for repairing this accident? Also with an visible counter of individual ip accesses so you can evaluate how often this can be happening... So, please, at least add a safety net/recipe in case that the unthinkable will happen .. (Murphy says that it will :) )
Thanks! Adrian
really know what they are doing from doing so. It's the same situation as 'rm -rf /boot' or 'rpm -e --allmatches kernel'. Of course, people are welcome to write specific plugins to achieve something similar to what Yum used to do.
Ales
On Fri, 3 Jan 2014 12:22:41 +0200 Adrian Sevcenco Adrian.Sevcenco@cern.ch wrote:
(Murphy says that it will :) )
Thanks! Adrian
I said nothing of the kind!
___ Regards, Frank www.frankly3d.com
On 01/03/2014 12:29 PM, Frank Murphy wrote:
On Fri, 3 Jan 2014 12:22:41 +0200 Adrian Sevcenco Adrian.Sevcenco@cern.ch wrote:
(Murphy says that it will :) )
Thanks! Adrian
I said nothing of the kind!
:)) Sorry, i was talking about this [1]
But, wouldn't you agree with the statement? (that if something can go wrong, it will) (from my experience, in software engineering this is a law of certainty :D )
[1] http://en.wikipedia.org/wiki/Murphy%27s_law
Thanks! Adrian
On Fri, Jan 3, 2014 at 12:14 AM, Joe Zeff joe@zeff.us wrote:
On 01/02/2014 03:42 PM, Patrick O'Callaghan wrote:
That would imply that someone actually took the decision to *remove* the protections against leaving the system with no installed kernel. Was this discussed? What were the proposers smoking?
It's always been a principle that *nix won't stop you from doing something stupid if it prevents me from doing something clever. I can't see how removing the installed kernel could be clever, but that might have been behind their thinking.
Note that I didn't say "prevent", I said "protect". Yum doesn't prevent it either, since you can easily get round the protection it provides if you want to, but it stops silly accidents from happening and that's a Good Thing (tm). Just like 'rm' will ask you to confirm when you try to remove a protected file, unless you use the '-f' option.
Actually, AIUI, the file isn't removed until the last program that's using it closes the file.
Of course, this is standard Unix semantics. The only time it will bite you is when the system wants to open a file that has been removed. I wouldn't want to rely on it not wanting to do that.
poc
Allegedly, on or about 02 January 2014, Ales Kozumplik sent:
In practice however, a user doesn't type 'dnf erase -y kernel' by accident and we don't feel the need to protect users who really know what they are doing from doing so. It's the same situation as 'rm -rf /boot' or 'rpm -e --allmatches kernel'.
I tend to agree, though it's a hazardous possibility, and the sort of thing that's usually covered by an alias, or required option, to the command.
While I might well install/upgrade a non-specific kernel. If I were going to remove a kernel, I'd be specifying which particular one. And those doing something just like "yum update", with no further parameters (perhaps, other than the less-than-clever "-y"), the installing of the latest kernel and removal of the oldest one, ought to be automatically handled the way it always has done (by the update routine).
Hi
On Thu, Jan 2, 2014 at 6:42 PM, Patrick O'Callaghan wrote:
That would imply that someone actually took the decision to *remove* the protections against leaving the system with no installed kernel. Was this discussed? What were the proposers smoking?
I don't think that is implied here. dnf changes the very core element of yum which is the custom dependency resolving logic and replaces it with libsolv while retaining nearly all the core command line options and configurations.
https://fedoraproject.org/wiki/Features/DNF
So, it is just that all the yum features are not rewritten to work against this fairly invasive change. Note that dnf was originally introduced in Fedora 18 and is proposed to become default only by Fedora 22 so there is a large amount of time that it has gone through testing and user feedback and still about an year left. So it is good to get your opinions in earlier by testing it now if you haven't done so already
Rahul
On Fri, Jan 3, 2014 at 10:22 AM, Adrian Sevcenco Adrian.Sevcenco@cern.ch wrote:
On 01/02/2014 12:54 PM, Ales Kozumplik wrote:
A question, I found the following on http://akozumpl.github.io/dnf/cli_vs_yum.html
"dnf erase kernel deletes all packages called kernel
In Yum, the running kernel is spared. There is no reason to keep this in DNF, the user can always specify concrete versions on the command line, e.g.:
dnf erase kernel-3.9.4"
So if I issue 'dnf erase kernel' all kernels will be removed, and I have no kernel anymore? Is that really a good thing? Should we not spare the running kernel? Or is there some rationale behind this that I am missing?
yes that's the idea. In practice however, a user doesn't type 'dnf erase -y kernel' by accident and we don't feel the need to protect users who
Just in case it happens, is it possible to prepare in advance a wiki page with instructions for repairing this accident?
Of course it's going to happen but it can happen with apt-get too, in the same way that someone can also delete "/boot" as Ales points out below. The solution's going to be, for example, to boot from a recovery DVD, chroot, and reinstall a kernel.
The problem's that it's a regression compared to yum and I'd point out to the dnf developers that it must be much simpler to grab the yum code that prevents the running kernel from being deleted and integrate it into dnf than have multiple angry threads here and on devel@ about this up to and beyond the release of F22. And it'll be good PR that they respond positively to feedback.
really know what they are doing from doing so. It's the same situation as 'rm -rf /boot' or 'rpm -e --allmatches kernel'. Of course, people are welcome to write specific plugins to achieve something similar to what Yum used to do.
-
Adrian Sevcenco -
Ahmad Samir -
Ales Kozumplik -
bruce -
Chris Murphy -
Erik P. Olsen -
Frank Murphy -
Jan Zelený -
Joe Zeff -
Lars E. Pettersson -
Markku Kolkka -
Mike Wohlgemuth -
Patrick O'Callaghan -
poma -
Rahul Sundaram -
Ralf Corsepius -
Suvayu Ali -
Tim -
Timothy Murphy -
Tom H