dnf even allows to uninstall RPM and systemd without warnings

drago01 drago01 at gmail.com
Mon Jun 23 17:07:44 UTC 2014


On Mon, Jun 23, 2014 at 7:01 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>
>
> Am 23.06.2014 18:47, schrieb Chris Adams:
>> Once upon a time, Bruno Wolff III <bruno at wolff.to> said:
>>> Try yum update when the oldest installed kernel (and the running
>>> kernel) is the only one that works and there is a new (still broken
>>> for your system) kernel update available. In that case one really
>>> wouldn't expect the running kernel be removed. Having to remove a
>>> specific kernel before doing an update (to make sure the wrong one
>>> wasn't removed) would be a pain.
>>
>> I guess I never considered it a pain.  That's exactly what I would do if
>> I knew a particular kernel was broken (remove specifically the broken
>> kernel).  I never knew yum/a yum plugin/whatever did "magic" stuff based
>> on the running kernel, trying to remove "special" packages like yum,
>> etc.
>
> be glad that you learned something new :-)
>
>
>> I have no problem with GUI tools having magic protections built in, but
>> I prefer CLI tools that don't try to out-think me.  yum/dnf already asks
>> for confirmation (which is more than up2date did); having additional
>> layers of protection/confirmation/whatever built-in seems excessive to
>> me.
>
> in general - agreed
>
> but not if it comes to destory the complete setup
>
>> It looks like there isn't even a way to override this behavior in yum.
>> I haven't wanted to remove all the kernels in a while (I guess since
>> before this was added); is the only way to bypass yum and use rpm?
>
> yes - simply because the chance that soemone wants to uninstall all
> kernels, yum, dnf and finalyl rpm itself is very low

You still did not give a simple case why someone with some sanity left
would do "yum remove rpm" or "yum remove yum" ... that makes no sense.
I can buy the kernel case as "clean up old kernels tool".
But if you don't know what you are doing you do not type random
commands, so can we go back to make decision based on *real use cases*
and not on obscure "what if" scenarios?

So again why do you expect someone to try to remove rpm or  glibc
using yum (or dnf)?


More information about the devel mailing list