<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 01/05/2014 08:33 PM, Reindl Harald
      wrote:<br>
    </div>
    <blockquote cite="mid:52CA07E8.20405@thelounge.net" type="cite">
      <pre wrap="">
"yum remove kernel" is a clean and sane way to remove all but not the running kernels
"distribute-command.sh 'yum -y remove kernel'" is used here for years on a ton of machines

why do you think that a *replacement* should come up not support this?
why do you think "we do not care and even allow remove dnf" is sane behavior?

hence that is why whatever calls itself a replacement for yum should *not*
support destroy the running system without whatever *force switch*
</pre>
    </blockquote>
    I don't like the weird partial functionality of this feature. It is
    apparently undocumented---actually, it'd be tricky to document it
    because it seems to protect some nebulous set of system facilities
    (running kernel, current yum, presumably RPM and runtime libraries;
    probably also grub; what else?). <br>
    <br>
    I actually agree that it makes sense to protect against deleting
    essential stuff built in, but an attempt  should simply fail, just
    like trying to delete dependencies of existing packages, similarly
    to 'rm -rf /' requiring explicit '--no-preserve-root'.<br>
    <br>
    Another point:  it shouldn't be hardwired into the package manager
    but rather result from package properties. I can see several ways to
    do it:<br>
     - an 'essentiality' property in the RPM file <br>
     - a yum/dnf configuration file specifying a set of protected
    packages<br>
     - a special, unremovable 'system' package that depends on kernel
    and dnf<br>
    <br>
    Last two would be preferable, because they allow tailoring the set
    of protected packages differently for a datacenter server vs. a
    network appliance, desktop, etc.<br>
  </body>
</html>