Am 23.06.2014 18:47, schrieb Chris Adams: > Once upon a time, Bruno Wolff III <bruno@xxxxxxxx> 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 frankly - it would be for sure not impossible to implement a "yum --disable-protections" - but that would be more wasted time given how often it is really what the user wants, but i have no problem with a "do what i say" the same applies to "rm -rf /" which is also protected and can be overriden with a CLI switch - for the same reason: it's hardly what the user really wanted to do
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
