Re: dnf even allows to uninstall RPM and systemd without warnings

Steve Clark <sclark@xxxxxxxxxxxxx> · Tue, 24 Jun 2014 06:44:10 -0400



    On 06/23/2014 06:54 PM, Gerald B. Cox
      wrote:

    
      First of all thank you for your reasoned response.
         I simply disagree.  
        

        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.  
          
            
          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. 
          

          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. 
        
      
        On Mon, Jun 23, 2014 at 12:26 PM,
          Przemek Klosowski <przemek.klosowski@xxxxxxxx>
          wrote:

          
              On 06/23/2014 11:51 AM, Gerald B. Cox wrote:

              
                  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. 

                
              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.

              
              First, the dependencies. Updates often involve chains of
              those, and I've seen cases, e.g. caused by a require bugs,
              where 

              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.

              
              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

              doesn't work, you are in a bind: 

              
               - you must upgrade because otherwise you will never get a
              fix

               - you can't upgrade because it'll delete the only running
              kernel, and the new one might not work

              
              It just makes a lot of sense to identify and protect a
              subset of packages whose removal is potentially
              irreversible.

            
    Hi Gerald,

    
    We get it. In a perfect world we wouldn't need any kind of
    validation on input because no one would ever make a mistake.

    
    -- 

      Stephen Clark

      NetWolves Managed Services, LLC.

      Director of Technology

      Phone: 813-579-3200

      Fax: 813-882-0209

      Email: steve.clark@xxxxxxxxxxxxx

      http://www.netwolves.com

    
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct