Re: announcement --- planned Yum replacement now ready for user testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
Erik
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
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




[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux