4 ms·

Has Fedora fixed its package management? I eventually deleted my Fedora partition and installed Ubuntu because package management was so painfully slow.

smarx007 5y ago
DNF is actually faster for me than APT on Ubuntu. 700 packages can get updated on 100Mbps link in a few minutes. Large package updates took 5+ minutes on Ubuntu.
- severino 5y ago
  I haven't used Fedora since 2015 or so, but at the time, I always felt DNF to be very slow or heavyweight. For example, I remember installing one random small package with few or no dependency installs at all could take something between 30 seconds and more than one minute, while apt-get would usually install the thing in a breeze. I wonder if this has changed.
  - smarx007 5y ago
    Ah, but 'dnf install' does also what 'apt-get update' does when necessary. So, dnf is faster for me than 'apt-get update && apt-get install'. I think there is a flag you can alias to force disable updating repos. Though the delay is rare for me.
    - mroche 5y ago
      The flag you're thinking of is '-C | --cacheonly'. It is very useful for doing stuff like 'dnf [search|rq|list|etc...]', but it is not allowed with upgrade/install type runs. dnf will do a check when running subcommands like 'install' to see if it _needs_ to update the cache data (as you noted), it won't always do it. There are a few factors that play in, but you can also adjust the cache expiry time in dnf.conf.
  - vondur 5y ago
    I believe some of the default settings for DNF are to blame. Editing the dnf.conf file to allow for more simultaneous downloads and selecting the closest mirrors can really speed it up.
  - tapoxi 5y ago
    Since 2015 they've been moving logic over to libdnf, which is written in C instead of Python.
  - curt15 5y ago
    That's because dnf metadata is massive compared to apt's. If you're installing something on Fedora for the first time, dnf needs to download about 100mb of metadata.
dralley 5y ago
It has improved a lot in the last few years, but a few things to point out: * It's slower partly due to the sheer quantity of metadata. This metadata can be quite useful sometimes but whether it's worth the price can be debated. * It's slower partly because DNF is transactional and is keeping track of the changes made to your system. This allows you to do things like view the history of your actions, rollback entire package operations, roll back every operation since $date, and so on. And also it can tell you whether any given package was installed directly by the user, installed as a dependency for something else, which repository it came from or whether it was installed directly from a file, and so on. All of that is super useful for auditing and recovering from screw-ups, but it means the package manager is doing a lot more work. * The default # of parallel package downloads is a little low. It gets a lot faster if you bump it up a bit.
washadjeffmad 5y ago
It seems you're being downvoted for a not very contentious experience. Running "dnf install $pkg" can take upwards of a minute (~40 seconds with default repos for me) while it invokes "dnf update". This can make the act of browsing through and installing lots of packages one by one take many times as long as using apt's cached lists. It's the only part of dnf I'm less than enamored by.
- BenjiWiebe 5y ago
  The 'dnf update'* part only runs sometimes, depending on your cache expiry setting in dnf.conf. If you run a single-package 'dnf install' a bunch of times in the same hour or two, then only the first one is slow while it runs the 'dnf update'* process. Actually it just updates the metadata - it won't install new versions of packages. It is like the apt-get update, but if you actually run 'dnf update' that's equivalent to apt's update and* upgrade.
bubblethink 5y ago
dnf tab completion is horribly slow on both RHEL and Fedora. I don't know why this is still a thing, but it has been always bad since the yum days in RHEL 5 or 6.

smarx007 5y ago

DNF is actually faster for me than APT on Ubuntu. 700 packages can get updated on 100Mbps link in a few minutes. Large package updates took 5+ minutes on Ubuntu.

severino 5y ago
I haven't used Fedora since 2015 or so, but at the time, I always felt DNF to be very slow or heavyweight. For example, I remember installing one random small package with few or no dependency installs at all could take something between 30 seconds and more than one minute, while apt-get would usually install the thing in a breeze. I wonder if this has changed.
- smarx007 5y ago
  Ah, but 'dnf install' does also what 'apt-get update' does when necessary. So, dnf is faster for me than 'apt-get update && apt-get install'. I think there is a flag you can alias to force disable updating repos. Though the delay is rare for me.
  - mroche 5y ago
    The flag you're thinking of is '-C | --cacheonly'. It is very useful for doing stuff like 'dnf [search|rq|list|etc...]', but it is not allowed with upgrade/install type runs. dnf will do a check when running subcommands like 'install' to see if it _needs_ to update the cache data (as you noted), it won't always do it. There are a few factors that play in, but you can also adjust the cache expiry time in dnf.conf.
- vondur 5y ago
  I believe some of the default settings for DNF are to blame. Editing the dnf.conf file to allow for more simultaneous downloads and selecting the closest mirrors can really speed it up.
- tapoxi 5y ago
  Since 2015 they've been moving logic over to libdnf, which is written in C instead of Python.
- curt15 5y ago
  That's because dnf metadata is massive compared to apt's. If you're installing something on Fedora for the first time, dnf needs to download about 100mb of metadata.

dralley 5y ago

It has improved a lot in the last few years, but a few things to point out: * It's slower partly due to the sheer quantity of metadata. This metadata can be quite useful sometimes but whether it's worth the price can be debated. * It's slower partly because DNF is transactional and is keeping track of the changes made to your system. This allows you to do things like view the history of your actions, rollback entire package operations, roll back every operation since $date, and so on. And also it can tell you whether any given package was installed directly by the user, installed as a dependency for something else, which repository it came from or whether it was installed directly from a file, and so on. All of that is super useful for auditing and recovering from screw-ups, but it means the package manager is doing a lot more work. * The default # of parallel package downloads is a little low. It gets a lot faster if you bump it up a bit.

washadjeffmad 5y ago

It seems you're being downvoted for a not very contentious experience. Running "dnf install $pkg" can take upwards of a minute (~40 seconds with default repos for me) while it invokes "dnf update". This can make the act of browsing through and installing lots of packages one by one take many times as long as using apt's cached lists. It's the only part of dnf I'm less than enamored by.

BenjiWiebe 5y ago
The 'dnf update'* part only runs sometimes, depending on your cache expiry setting in dnf.conf. If you run a single-package 'dnf install' a bunch of times in the same hour or two, then only the first one is slow while it runs the 'dnf update'* process. Actually it just updates the metadata - it won't install new versions of packages. It is like the apt-get update, but if you actually run 'dnf update' that's equivalent to apt's update and* upgrade.

bubblethink 5y ago

dnf tab completion is horribly slow on both RHEL and Fedora. I don't know why this is still a thing, but it has been always bad since the yum days in RHEL 5 or 6.