DNF vs. YUM

Kevin Martin ktmdms at gmail.com
Thu Mar 13 14:17:46 UTC 2014


On 03/13/2014 09:04 AM, Mark Haney wrote:
> 
> 
> On 03/13/14 09:52, Tethys wrote:
>> On Thu, Mar 13, 2014 at 1:48 PM, Jan Zelený <jzeleny at redhat.com>
>> wrote:
> 
>>> The metadata are quite large and downloading them every single
>>> time is time consuming.
> 
>> I can't think of an occasion on which I'd want to say "update this 
>> package, but not to the latest version". For installing new
>> software, maybe. But updating an already installed package? I'd say
>> the default should be to check metadata in that instance.
> 
>> Tet
> 
> 
> Comparing apt and yum is silly.  But I see the point.  I've never been
> personally all that impressed with how Debian updates packages.  Fast,
> maybe.  Consistent?  I have always had a real problem with .deb
> packages and updating configuration files.  Invariably I have config
> files that don't get updated and don't work with the new versions.
> Then I have to spend precious time updating the files by hand.
> Personally, yum does a much better job of that.
> 
> Making RPMs and yum more efficient is great, don't get me wrong.  But
> I don't care about speed.  I typically manually run updates from the
> CLI every day.  I prefer seeing the progress that way than from a GUI.
>  But, I guess that comes from years of being a command line jockey.
> 
> For example, I just did a full restore of Win7 on my Samsung netbook.
>  I had 82 updates to install this morning (I installed almost 200
> yesterday).  It took TWO HOURS to go through the installation process
> (~150MB of updates) and I still had 16 updates fail to install.  The
> error code in the dialog was useless.  That is precisely why I like
> updating from the CLI.
> 
> I'm sure I'm in the minority of the general population, but there it is.
> 
> 
I'm with you Mark...CLi all the way with the updates.  And I like what DNF does with skipping repos it can't find.  BTW, if you set
"metadata_expire=-1" in /etc/dnf/dnf.conf then the metadata *always downloads from the repo.   One thing I don't get is why I see
these errors from time to time (like this morning):

[MIRROR] valgrind-3.9.0-8.fc21_3.9.0-9.svn20140311r13869.fc21.x86_64.drpm: Curl error: Access denied to remote resource for
ftp://mirror.uoregon.edu/fedora/development/rawhide/x86_64/os/drpms/valgrind-3.9.0-8.fc21_3.9.0-9.svn20140311r13869.fc21.x86_64.drpm
[MIRROR] valgrind-3.9.0-8.fc21_3.9.0-9.svn20140311r13869.fc21.x86_64.drpm: Status code: 404 for
http://mirror.uoregon.edu/fedora/linux/development/rawhide/x86_64/os/drpms/valgrind-3.9.0-8.fc21_3.9.0-9.svn20140311r13869.fc21.x86_64.drpm

Somebody not maintaining their mirrors correctly or somebody not maintaining the mirror list correctly?

Oh, and one other thing I noticed recently is that something has changed in the regex handling.  From time to time I would "sudo dnf
--enablerepo=fedora*testing upgrade" and that worked for awhile but now I get an error that the repo fedora*testing can't be found.
 However, if I change that to --enablerepo=*testing* then it goes thru and parses it just fine.  BLEAH!!! It's these kinds of little
gotchas that drive a person crazy!

Kevin




More information about the users mailing list