<div dir="ltr">First of all thank you for your reasoned response. I simply disagree. <div><br></div><div>I understand the fact about require bugs, and the tons of dependent packages. I've seen that also when I've tried to remove a package and noticed it had a myriad of dependencies which would also be removed. However, when I see this, I simply respond "N" when I'm asked if it is OK to proceed. I also cringe when I see the "-y or --assumeyes" option mentioned. IMO that is just inviting disaster. I'm surprised no one is "demanding" that be removed. It is dangerous. <div>
<br></div><div>Regarding your kernel comment, I've been using Fedora since Redhat 6.2 and DNF since it first came out and I've never encountered this. When I update the kernel, it leaves the prior two on my system for rollback, so I have no idea what you're talking about. Yes, if you manually enter "dnf remove kernel" it will come back with a list of all your installed kernels, but again, you have to tell it "YES" to proceed. </div>
<div><br></div><div>That said, my concern is that valuable developer time be devoted to something which basically is to assist a small fraction of people who are careless, can't be bothered to read or both. </div></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 23, 2014 at 12:26 PM, Przemek Klosowski <span dir="ltr"><<a href="mailto:przemek.klosowski@nist.gov" target="_blank">przemek.klosowski@nist.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 06/23/2014 11:51 AM, Gerald B. Cox
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<pre style="white-space:pre-wrap;word-wrap:break-word;width:50em;color:rgb(0,0,0)">This has got to be the silliest thing I've ever seen, but whatever. You enter the command dnf remove dnf, and guess what? It removes dnf. You enter the command dnf remove kernel, and guess what, it removes the kernel. What a concept, it does what you tell it to do.
</pre>
</div>
</blockquote>
You present it as simple, but it's really trickier than you imply
for several reasons. We discussed several special cases, which you
must have missed so let me recall those for your benefit.<br>
<br>
First, the dependencies. Updates often involve chains of those, and
I've seen cases, e.g. caused by a require bugs, where <br>
suddenly some system libraries end up scheduled for removal,
dragging along tons of dependent packages. Yes, 'yum update' will
then ask for confirmation, but it just isn't scalable---the
equivalent of 'yum -y update' must be reliable and recoverable even
if things go wobbly.<br>
<br>
Second, kernel updates deleting all old kernels can delete the only
running kernel. You can't just say "don't ship broken kernel
upgrades" because it's a per-system problem---new ones work for most
people but if you are the unlucky person for whom it<br>
doesn't work, you are in a bind: <br>
<br>
- you must upgrade because otherwise you will never get a fix<br>
- you can't upgrade because it'll delete the only running kernel,
and the new one might not work<br>
<br>
It just makes a lot of sense to identify and protect a subset of
packages whose removal is potentially irreversible.<br>
</div>
<br>--<br>
devel mailing list<br>
<a href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/devel" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/devel</a><br>
Fedora Code of Conduct: <a href="http://fedoraproject.org/code-of-conduct" target="_blank">http://fedoraproject.org/code-of-conduct</a><br></blockquote></div><br></div>