Suvayu Ali <fatkasuvayu+linux@xxxxxxxxx> wrote: >> I hope this will be done *fast*, because I have to "clean all" >> *everytime* checking for updates. Otherwise, no updates are shown, even >> though they exist. This is a major bug. > > I'm sorry but "clean all" is not necessary at all! "clean metadata" or > "clean expire-cache" should be sufficient. In practice, there's not much of a difference between "clean all" or just "clean metadata". Because both require the update/upgrade command to download all stuff from the network and build to whole meta database from scratch, even if that wouldn't be necessary. For the typical desktop PC, "clean metadata" is not a time-saver compared to "clean all". Just more letters to type. "clean metadata" may make sense if you add "--disablerepo=fedora", because this really saves bandwidth and CPU for the update/upgrade. Btw, "clean expire-cache" (or --refresh) won't do the trick to get the latest updates available. (However, it's still better than just update/upgrade without anything else.) The design of yum/dnf is somewhat flawed. I totally understand that some caching makes sense so that metadata isn't checked, downloaded or built for every single call to yum/dnf. However, if somebody runs "dnf upgrade" on the command shell then he clearly wants the latest updates. Right now! No caching or other magic involved. That's the whole point of running "dnf upgrade" manually, otherwise the user would have left the whole updating business to some automated background task. > That said, I sometimes do not understand what's the harm in getting > updates few hours later. Caching might be cool for automated tasks (eg, cron jobs or background processes) and also for some actions that do not require up-to-date metadata. But if the user wants to download an update he should get the update. This issue comes up for years. And there's always this debate about "clean all" vs. "clean metadata" which in fact isn't a big difference in the real world, and - what is much more important - both won't solve the underlying problem, so the very same issue comes up again and again. Greetings, Andreas -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
