Re: dnf-0.4.11
On 14. 1. 2014 at 23:21:15, Peter Oliver wrote: On Mon, 13 Jan 2014, Miroslav Suchý wrote: On 01/13/2014 09:57 AM, Frank Murphy wrote: On Mon, 13 Jan 2014 09:53:53 +0100 Miroslav Suchý msu...@redhat.com wrote: On 01/13/2014 08:56 AM, Frank Murphy wrote: to be certain you can do dnf(yum) --enablerepo=* clean all if your intention is truly to remove all cache. Not true if you ever used --releasever option. dnf --enablerepo=* --releasever=* clean all ? No. This command is accepted (to my surprise). But it delete nothing. And just create new directory sturcture in '/var/cache/yum/x86_64/*'. Is there, then, room for a new, clean all-including-disabled option, assuming someone could come up with a snappier name for it than that? Quite frankly I don't think that's even doable in any other way than rm -rf /var/cache/dnf/*, as dnf can loose track of the old data when you use -- releasever, for example when you update your entire distro with it. The only way I can see this done is to implement a plugin that would be an alias to the rm -rf action. IIRC plugins can add their own subcommands too. If you think such a plugin is required or nice to have, I encourage you to write it, dnf's API is well documented for that. Then you can either propose it for inclusion to dnf core plugins or create a separated package with the plugin. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 13 Jan 2014, Miroslav Suchý wrote: On 01/13/2014 09:57 AM, Frank Murphy wrote: On Mon, 13 Jan 2014 09:53:53 +0100 Miroslav Suchý msu...@redhat.com wrote: On 01/13/2014 08:56 AM, Frank Murphy wrote: to be certain you can do dnf(yum) --enablerepo=* clean all if your intention is truly to remove all cache. Not true if you ever used --releasever option. dnf --enablerepo=* --releasever=* clean all ? No. This command is accepted (to my surprise). But it delete nothing. And just create new directory sturcture in '/var/cache/yum/x86_64/*'. Is there, then, room for a new, clean all-including-disabled option, assuming someone could come up with a snappier name for it than that? -- Peter Oliver-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
If you continue reading the thread you'll see what happened (short story: too late fo rme) --alec On Mon, Jan 13, 2014 at 8:59 AM, Frank Murphy frankl...@gmail.com wrote: On Mon, 13 Jan 2014 00:43:13 +0100 Alec Leamas leamas.a...@gmail.com wrote: First of all, this is not, and have never been a question of disabled repos. Or should not have. yum clean all refers to cleaning all metadata, not all repos. It only operates on one single repo, be it implicit (the default link) or an explicit -r option. man yum CLEAN OPTIONS The following are the ways which you can invoke yum in clean mode. Note that all files in the commands below means all files in currently enabled repositories. If you want to also clean any (temporarily) disabled repositories you need to use --enablerepo='*' option. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 13 Jan 2014 09:36:38 +0100 Alec Leamas leamas.a...@gmail.com wrote: If you continue reading the thread you'll see what happened (short story: too late fo rme) --alec Refreshing my email would have helped, too early for me :( ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Sun, 12 Jan 2014 14:06:30 -0500 Garry T. Williams gtwilli...@gmail.com wrote: sudo dnf --enablerepo=updates-testing clean expire-cache sudo dnf --enablerepo=updates-testing upgrade kernel\* You can also after some research modify the dnf-makecache.service file to change the frequency of makecache. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 01/13/2014 08:56 AM, Frank Murphy wrote: to be certain you can do dnf(yum) --enablerepo=* clean all if your intention is truly to remove all cache. Not true if you ever used --releasever option. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 01/13/2014 07:32 AM, Miroslav Suchy wrote: Let leave yum as is, but let try to redefine this behavior for dnf: https://bugzilla.redhat.com/show_bug.cgi?id=1052020 If you want this change please vote for this bug (by adding yourself to CC of that bug). Otherwise it will stay as CLOSED WONTFIX. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 13 Jan 2014 09:53:53 +0100 Miroslav Suchý msu...@redhat.com wrote: On 01/13/2014 08:56 AM, Frank Murphy wrote: to be certain you can do dnf(yum) --enablerepo=* clean all if your intention is truly to remove all cache. Not true if you ever used --releasever option. dnf --enablerepo=* --releasever=* clean all ? ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 13/01/14 08:45, Frank Murphy wrote: On Sun, 12 Jan 2014 14:06:30 -0500 Garry T. Williams gtwilli...@gmail.com wrote: sudo dnf --enablerepo=updates-testing clean expire-cache sudo dnf --enablerepo=updates-testing upgrade kernel\* You can also after some research modify the dnf-makecache.service file to change the frequency of makecache. I don't think that will help as that service simply controls when it considers updating - the expire_metadata setting still applies, so by default that will only do anything when 48 hours have elapsed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 13 Jan 2014 09:33:09 + Tom Hughes t...@compton.nu wrote: the expire_metadata setting still applies, Where is this setting? besides metadata expire in *.repos. I couldn't find in on the wiki ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 13 Jan 2014 09:51:27 + Frank Murphy frankl...@gmail.com wrote: Where is this setting? besides metadata expire in *.repos. I couldn't find in on the wiki Duh! man 8 dnf.conf, so behaviour can be changed without running dnf clean * dnf update for those that may want it, by adding it in. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 13 Jan 2014 09:33:09 + Tom Hughes t...@compton.nu wrote: You can also after some research modify the dnf-makecache.service file to change the frequency of makecache. I don't think that will help as that service simply controls when it considers updating - the expire_metadata setting still applies, so by default that will only do anything when 48 hours have elapsed. But it may prevent it running every 3 hours, if not needed by user at that interval ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
Am 13.01.2014 09:57, schrieb Frank Murphy: On Mon, 13 Jan 2014 09:53:53 +0100 Miroslav Suchý msu...@redhat.com wrote: On 01/13/2014 08:56 AM, Frank Murphy wrote: to be certain you can do dnf(yum) --enablerepo=* clean all if your intention is truly to remove all cache. Not true if you ever used --releasever option. dnf --enablerepo=* --releasever=* clean all? is also not all because the likely other remaining caches without releasever is ignored signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 01/13/2014 09:57 AM, Frank Murphy wrote: On Mon, 13 Jan 2014 09:53:53 +0100 Miroslav Suchý msu...@redhat.com wrote: On 01/13/2014 08:56 AM, Frank Murphy wrote: to be certain you can do dnf(yum) --enablerepo=* clean all if your intention is truly to remove all cache. Not true if you ever used --releasever option. dnf --enablerepo=* --releasever=* clean all ? No. This command is accepted (to my surprise). But it delete nothing. And just create new directory sturcture in '/var/cache/yum/x86_64/*'. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 13 Jan 2014 14:38:39 +0100 Miroslav Suchý msu...@redhat.com wrote: No. This command is accepted (to my surprise). But it delete nothing. And just create new directory sturcture in '/var/cache/yum/x86_64/*'. That does suck then if someone with more that F20 cache needs to clean. as Harald posted you are stuck with rm -rf /var/cache/yum* or this case ~/cache/dnf* ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 2014-01-13 at 08:45 +, Frank Murphy wrote: On Sun, 12 Jan 2014 14:06:30 -0500 Garry T. Williams gtwilli...@gmail.com wrote: sudo dnf --enablerepo=updates-testing clean expire-cache sudo dnf --enablerepo=updates-testing upgrade kernel\* You can also after some research modify the dnf-makecache.service file to change the frequency of makecache. It's a lot cleaner to just define a metadata expiry time in the repository config file. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 13 Jan 2014 10:16:52 -0800 Adam Williamson awill...@redhat.com wrote: You can also after some research modify the dnf-makecache.service file to change the frequency of makecache. It's a lot cleaner to just define a metadata expiry time in the repository config file. Discovered after writing it easier disable the timer, and do your own schedule. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 1-9-14 15:43:50 Ales Kozumplik wrote: New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! I see this using 0.4.11. What am I doing wrong? garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\* [sudo] password for garry: Resolving dependencies -- Starting dependency resolution -- Finished dependency resolution Dependencies resolved. Nothing to do. garry@vfr$ sudo yum --enablerepo=updates-testing update kernel\* Loaded plugins: langpacks, refresh-packagekit [snip] Resolving Dependencies -- Running transaction check --- Package kernel.x86_64 0:3.12.7-300.fc20 will be installed --- Package kernel-devel.x86_64 0:3.12.7-300.fc20 will be installed --- Package kernel-headers.x86_64 0:3.12.6-300.fc20 will be updated --- Package kernel-headers.x86_64 0:3.12.7-300.fc20 will be an update -- Finished Dependency Resolution -- Finding unneeded leftover dependencies Found and removing 0 unneeded dependencies -- Running transaction check --- Package kernel.x86_64 0:3.11.8-200.fc19 will be erased --- Package kernel-devel.x86_64 0:3.11.8-200.fc19 will be erased -- Finished Dependency Resolution Dependencies Resolved PackageArch VersionRepository Size Installing: kernel x86_64 3.12.7-300.fc20updates-testing 30 M kernel-devel x86_64 3.12.7-300.fc20updates-testing 8.5 M Updating: kernel-headers x86_64 3.12.7-300.fc20updates-testing 913 k Removing: kernel x86_64 3.11.8-200.fc19@updates/19 128 M kernel-devel x86_64 3.11.8-200.fc19@updates/19 31 M Transaction Summary Install 2 Packages Upgrade 1 Package Remove 2 Packages Total download size: 40 M Is this ok [y/d/N]: n Exiting on user command Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx.2014-01-12.11-20.aiCKeH.yumtx garry@vfr$ sudo dnf clean all Cleaning repos: fedora rpmfusion-free-updates adobe-linux-x86_64 : rpmfusion-nonfree-updates rpmfusion-free updates google-chrome : rpmfusion-nonfree Cleaning up Everything garry@vfr$ sudo dnf --enablerepo=updates-testing upgrade kernel\* Fedora 20 - x86_64 144 kB/s | 36 MB 04:14 RPM Fusion for Fedora 20 - Free - Updates97 kB/s | 72 kB 00:00 Adobe Systems Incorporated 8.7 kB/s | 1.8 kB 00:00 RPM Fusion for Fedora 20 - Nonfree - Updates 29 kB/s | 13 kB 00:00 RPM Fusion for Fedora 20 - Free 124 kB/s | 487 kB 00:03 Fedora 20 - x86_64 - Updates125 kB/s | 12 MB 01:38 google-chrome26 kB/s | 3.1 kB 00:00 RPM Fusion for Fedora 20 - Nonfree 113 kB/s | 289 kB 00:02 Resolving dependencies -- Starting dependency resolution -- Finished dependency resolution Dependencies resolved. Nothing to do. garry@vfr$ -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 1-12-14 11:39:35 Rahul Sundaram wrote: On Sun, Jan 12, 2014 at 11:30 AM, Garry T. Williams wrote: On 1-9-14 15:43:50 Ales Kozumplik wrote: New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! I see this using 0.4.11. What am I doing wrong? http://dnf.baseurl.org/2014/01/02/dnf-update-and-yum-update-produce-different-output/ Yes, I have reviewed all that. That reference says, The bottom line is: unless a real update problem occurs (i.e. DNF refuses to update a package that Yum updates) with the same set of metadata (dnf clean all; yum clean all), this is not an issue. I did dnf clean all and the updates-testing package is still not found by dnf. Hey, I'm just testing. It looks like a bug, but I wanted to see if I was overlooking something. -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 1-12-14 18:18:00 M A Young wrote: On Sun, 12 Jan 2014, Garry T. Williams wrote: On 1-9-14 15:43:50 Ales Kozumplik wrote: New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! I see this using 0.4.11. What am I doing wrong? garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\* [sudo] password for garry: Resolving dependencies -- Starting dependency resolution -- Finished dependency resolution Dependencies resolved. Nothing to do. Try dnf clean expire-cache first. I don't think dnf checks whether its metadata is up to date as frequently as yum does. Ha! That was it. sudo dnf --enablerepo=updates-testing clean expire-cache sudo dnf --enablerepo=updates-testing upgrade kernel\* did the trick. -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 12 January 2014 21:06, Garry T. Williams gtwilli...@gmail.com wrote: On 1-12-14 18:18:00 M A Young wrote: On Sun, 12 Jan 2014, Garry T. Williams wrote: On 1-9-14 15:43:50 Ales Kozumplik wrote: New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! I see this using 0.4.11. What am I doing wrong? garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\* [sudo] password for garry: Resolving dependencies -- Starting dependency resolution -- Finished dependency resolution Dependencies resolved. Nothing to do. Try dnf clean expire-cache first. I don't think dnf checks whether its metadata is up to date as frequently as yum does. Ha! That was it. sudo dnf --enablerepo=updates-testing clean expire-cache sudo dnf --enablerepo=updates-testing upgrade kernel\* did the trick. 'dnf clean all' does what 'clean expire-cache' does, and more. (check the man page) It could be that dnf picked another mirror this time, or it used the same mirror and that mirror has synced with the master mirror(s). -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Ahmad Samir -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 1-12-14 11:30:31 you wrote: On 1-9-14 15:43:50 Ales Kozumplik wrote: New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! I see this using 0.4.11. What am I doing wrong? [snip] garry@vfr$ sudo dnf clean all Cleaning repos: fedora rpmfusion-free-updates adobe-linux-x86_64 : rpmfusion-nonfree-updates rpmfusion-free updates google-chrome : rpmfusion-nonfree Cleaning up Everything garry@vfr$ sudo dnf --enablerepo=updates-testing upgrade kernel\* The real problem was not including the updates-testing repo in the clean all command. And yes, as Michael commented, dnf doesn't expire meta-data as often as yum. -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 1-12-14 20:27:26 Reindl Harald wrote: dnf clean all without dnf --enablerepo=updates-testing clean all does exactly *nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation Yeah, I feel pretty stupid now. -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
Am 12.01.2014 21:38, schrieb Garry T. Williams: On 1-12-14 20:27:26 Reindl Harald wrote: dnf clean all without dnf --enablerepo=updates-testing clean all does exactly *nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation Yeah, I feel pretty stupid now no - the better question is why all does not mean really *all* however, instead of yum clean all i use rm -rf /var/cache/yum/* for al least 7 years because *that* means really all, in case of DNF most likely rm -rf /var/cache/dnf/* would be required signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 01/12/2014 08:27 PM, Reindl Harald wrote: dnf clean all without dnf --enablerepo=updates-testing clean all does exactly*nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation And is this correct behavior? (and yum behaves same way, so same question apply to yum as well). Man page for yum state: yum clean metadata Eliminate all of the files which yum uses to determine the remote availability of packages. Using this option will force yum to download all the metadata the next time it is run. There is no statement that it apply only for *currently enabled* repository. I would expect that it clean *all* metadata. I was recently very surprised that when I done : # rpm -q yum yum-3.4.3-128.fc20.noarch # yum clean all ... # du -sh /var/cache/yum/x86_64/* 225M/var/cache/yum/x86_64/19 111M/var/cache/yum/x86_64/20 406M/var/cache/yum/x86_64/rawhide that there is a lot of data in /var. To be precise - after this operation I would expect that /var/cache/yum/x86_64/ would have zero size. And not 730 MB. DNF is on the same boat: # rpm -q dnf dnf-0.4.9-1.fc20.noarch # dnf clean all Cleaning repos: fedora rpmfusion-free-updates adobe-linux-x86_64 Dropbox rpmfusion-nonfree-updates rpmfusion-free updates rpmfusion-nonfree Cleaning up Everything # du -sh /var/cache/dnf/x86_64/* 114M/var/cache/dnf/x86_64/19 34M /var/cache/dnf/x86_64/20 Do others feel that this is correct or incorrect behavior? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
Am 12.01.2014 22:42, schrieb Miroslav Suchy: On 01/12/2014 08:27 PM, Reindl Harald wrote: dnf clean all without dnf --enablerepo=updates-testing clean all does exactly *nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation And is this correct behavior? (and yum behaves same way, so same question apply to yum as well). no, i only explained the current state of play looking at the word all and it's meaing clearly *no* looking at the thread and result of the behavior clearely *no* looking at that people use updates-testing with --enablerepo *no* looking at the fact that i do not trust the word all clearly *no* Man page for yum state: yum clean metadata Eliminate all of the files which yum uses to determine the remote availability of packages. Using this option will force yum to download all the metadata the next time it is run. There is no statement that it apply only for *currently enabled* repository. I would expect that it clean *all* metadata. I was recently very surprised that when I done : # rpm -q yum yum-3.4.3-128.fc20.noarch # yum clean all ... # du -sh /var/cache/yum/x86_64/* 225M/var/cache/yum/x86_64/19 111M/var/cache/yum/x86_64/20 406M/var/cache/yum/x86_64/rawhide that there is a lot of data in /var. To be precise - after this operation I would expect that /var/cache/yum/x86_64/ would have zero size. And not 730 MB. and that is why i switched 7 years ago to rm -rf /var/cache/yum* signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
I have come to understand that for yum, commands like clean only applies to the actual buildroot. So without a -r argument, the cleaning is done on the default root, whatever this might be(?). Actually, there is probably nothing wrong with this - it works fine when using the -r option. Problems comes without it, when one thinks it applies to all buildroots. It would perhaps make sense outputting something like Using buildroot foo when there is no -r on the command line(?). On Sun, Jan 12, 2014 at 10:47 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 12.01.2014 22:42, schrieb Miroslav Suchy: On 01/12/2014 08:27 PM, Reindl Harald wrote: dnf clean all without dnf --enablerepo=updates-testing clean all does exactly *nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation And is this correct behavior? (and yum behaves same way, so same question apply to yum as well). no, i only explained the current state of play looking at the word all and it's meaing clearly *no* looking at the thread and result of the behavior clearely *no* looking at that people use updates-testing with --enablerepo *no* looking at the fact that i do not trust the word all clearly *no* Man page for yum state: yum clean metadata Eliminate all of the files which yum uses to determine the remote availability of packages. Using this option will force yum to download all the metadata the next time it is run. There is no statement that it apply only for *currently enabled* repository. I would expect that it clean *all* metadata. I was recently very surprised that when I done : # rpm -q yum yum-3.4.3-128.fc20.noarch # yum clean all ... # du -sh /var/cache/yum/x86_64/* 225M/var/cache/yum/x86_64/19 111M/var/cache/yum/x86_64/20 406M/var/cache/yum/x86_64/rawhide that there is a lot of data in /var. To be precise - after this operation I would expect that /var/cache/yum/x86_64/ would have zero size. And not 730 MB. and that is why i switched 7 years ago to rm -rf /var/cache/yum* -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
from a developers point of view the current behavior is clear and perfect what is not enabled is handeled as it would not exist means: repos with enabled=0 are completly ignored until --enablrepo with no but and if - clear and straight logical decision from a users point of view all has a different meaning well, i can live with both because i am developer and i know how these things are working, i know that the codebase is much cleaner the way it works currently personally i would draw the line in case if it is my code and act like the user expects it, not in general, but in that case of meaningless data which are refreshed and no bad impact if lost Am 12.01.2014 22:57, schrieb Alec Leamas: I have come to understand that for yum, commands like clean only applies to the actual buildroot. So without a -r argument, the cleaning is done on the default root, whatever this might be(?). Actually, there is probably nothing wrong with this - it works fine when using the -r option. Problems comes without it, when one thinks it applies to all buildroots. It would perhaps make sense outputting something like Using buildroot foo when there is no -r on the command line(?). On Sun, Jan 12, 2014 at 10:47 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 12.01.2014 22:42, schrieb Miroslav Suchy: On 01/12/2014 08:27 PM, Reindl Harald wrote: dnf clean all without dnf --enablerepo=updates-testing clean all does exactly *nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation And is this correct behavior? (and yum behaves same way, so same question apply to yum as well). no, i only explained the current state of play looking at the word all and it's meaing clearly *no* looking at the thread and result of the behavior clearely *no* looking at that people use updates-testing with --enablerepo *no* looking at the fact that i do not trust the word all clearly *no* Man page for yum state: yum clean metadata Eliminate all of the files which yum uses to determine the remote availability of packages. Using this option will force yum to download all the metadata the next time it is run. There is no statement that it apply only for *currently enabled* repository. I would expect that it clean *all* metadata. I was recently very surprised that when I done : # rpm -q yum yum-3.4.3-128.fc20.noarch # yum clean all ... # du -sh /var/cache/yum/x86_64/* 225M/var/cache/yum/x86_64/19 111M/var/cache/yum/x86_64/20 406M/var/cache/yum/x86_64/rawhide that there is a lot of data in /var. To be precise - after this operation I would expect that /var/cache/yum/x86_64/ would have zero size. And not 730 MB. and that is why i switched 7 years ago to rm -rf /var/cache/yum* signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
Well, IMHO the docs are actually quite clear on that 'all' refers to all metadata rather than all repositories. That said, perhaps enough people has been confused by this to make some kind of improvement motivated. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Sun, Jan 12, 2014 at 5:23 PM, Alec Leamas wrote: Well, IMHO the docs are actually quite clear on that 'all' refers to all metadata rather than all repositories. That said, perhaps enough people has been confused by this to make some kind of improvement motivated. I am pretty sure if you flip the current behavior and make 'clean all' act on disabled repos, some other subset of users (e.g. me) will be confused. Best, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
Am 13.01.2014 00:17, schrieb Orcan Ogetbil: On Sun, Jan 12, 2014 at 5:23 PM, Alec Leamas wrote: Well, IMHO the docs are actually quite clear on that 'all' refers to all metadata rather than all repositories. That said, perhaps enough people has been confused by this to make some kind of improvement motivated. I am pretty sure if you flip the current behavior and make 'clean all' act on disabled repos, some other subset of users (e.g. me) will be confused please explain how you would be confused clean all would only delete metadata which are anyways refreshed at the next call with whatever repo enabled and clean all is there to make sure that *all* metadata is refreshed instead use maybe outdated signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
First of all, this is not, and have never been a question of disabled repos. Or should not have. yum clean all refers to cleaning all metadata, not all repos. It only operates on one single repo, be it implicit (the default link) or an explicit -r option. This is what confuses. I know: been there done that... Even though the documents are clear, the behaviour does indeed cause confusion for some reason even though it's well-defined. Of course, changing semantics for yum is a bad idea, agreed. I did not have anything like that in mind. At most, some info on what buildroot which is used in the output, or similar measures. For dnf, I guess one could possibly think somewhat more free. Personally, I tend to think that it's the implicit buildroot which causes much of this trouble. What happens if we get rid of the implcit buildroot, forcing us to specify it every time? With 'default' as a legal option? Personally, I tend to think this might make things a little clearer. Just my 5 öre --alec On Mon, Jan 13, 2014 at 12:17 AM, Orcan Ogetbil oget.fed...@gmail.comwrote: On Sun, Jan 12, 2014 at 5:23 PM, Alec Leamas wrote: Well, IMHO the docs are actually quite clear on that 'all' refers to all metadata rather than all repositories. That said, perhaps enough people has been confused by this to make some kind of improvement motivated. I am pretty sure if you flip the current behavior and make 'clean all' act on disabled repos, some other subset of users (e.g. me) will be confused. Best, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
Am 13.01.2014 00:43, schrieb Alec Leamas: First of all, this is not, and have never been a question of disabled repos. Or should not have. yum clean all refers to cleaning all metadata, not all repos. It only operates on one single repo, be it implicit (the default link) or an explicit -r option. This is what confuses. I know: been there done that... Even though the documents are clear, the behaviour does indeed cause confusion for some reason even though it's well-defined. Of course, changing semantics for yum is a bad idea, agreed. I did not have anything like that in mind. At most, some info on what buildroot which is used in the output, or similar measures. For dnf, I guess one could possibly think somewhat more free. Personally, I tend to think that it's the implicit buildroot which causes much of this trouble. What happens if we get rid of the implcit buildroot, forcing us to specify it every time? With 'default' as a legal option? Personally, I tend to think this might make things a little clearer. *what* is a buildroot in case of YUM/DNF? in any case nothing relevant for a user and said that i use Fedora and YUM for many years, the only conetxt of buildroot for me is rpmbuild and that has no context to YUM/DNF at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
Yes, sorry, forget what I wrote. I messed up mock with yum, that's why. It's too late for me to chime in here. Sorry for the noise. On Mon, Jan 13, 2014 at 12:49 AM, Reindl Harald h.rei...@thelounge.netwrote: Am 13.01.2014 00:43, schrieb Alec Leamas: First of all, this is not, and have never been a question of disabled repos. Or should not have. yum clean all refers to cleaning all metadata, not all repos. It only operates on one single repo, be it implicit (the default link) or an explicit -r option. This is what confuses. I know: been there done that... Even though the documents are clear, the behaviour does indeed cause confusion for some reason even though it's well-defined. Of course, changing semantics for yum is a bad idea, agreed. I did not have anything like that in mind. At most, some info on what buildroot which is used in the output, or similar measures. For dnf, I guess one could possibly think somewhat more free. Personally, I tend to think that it's the implicit buildroot which causes much of this trouble. What happens if we get rid of the implcit buildroot, forcing us to specify it every time? With 'default' as a legal option? Personally, I tend to think this might make things a little clearer. *what* is a buildroot in case of YUM/DNF? in any case nothing relevant for a user and said that i use Fedora and YUM for many years, the only conetxt of buildroot for me is rpmbuild and that has no context to YUM/DNF at all -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 12 January 2014 21:27, Reindl Harald h.rei...@thelounge.net wrote: Am 12.01.2014 20:24, schrieb Ahmad Samir: On 12 January 2014 21:06, Garry T. Williams gtwilli...@gmail.com wrote: On 1-12-14 18:18:00 M A Young wrote: On Sun, 12 Jan 2014, Garry T. Williams wrote: On 1-9-14 15:43:50 Ales Kozumplik wrote: New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! I see this using 0.4.11. What am I doing wrong? garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\* [sudo] password for garry: Resolving dependencies -- Starting dependency resolution -- Finished dependency resolution Dependencies resolved. Nothing to do. Try dnf clean expire-cache first. I don't think dnf checks whether its metadata is up to date as frequently as yum does. Ha! That was it. sudo dnf --enablerepo=updates-testing clean expire-cache sudo dnf --enablerepo=updates-testing upgrade kernel\* did the trick. 'dnf clean all' does what 'clean expire-cache' does, and more. (check the man page) dnf clean all without dnf --enablerepo=updates-testing clean all does exactly *nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation Right, I missed that bit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Ahmad Samir -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 01/12/2014 11:23 PM, Alec Leamas wrote: Well, IMHO the docs are actually quite clear on that 'all' refers to all metadata rather than all repositories. That said, perhaps enough people has been confused by this to make some kind of improvement motivated. Let leave yum as is, but let try to redefine this behavior for dnf: https://bugzilla.redhat.com/show_bug.cgi?id=1052020 Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 13 Jan 2014 07:51:22 +0200 Ahmad Samir ahmadsamir3...@gmail.com wrote: Right, I missed that bit. to be certain you can do dnf(yum) --enablerepo=* clean all if your intention is truly to remove all cache. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 13 Jan 2014 00:43:13 +0100 Alec Leamas leamas.a...@gmail.com wrote: First of all, this is not, and have never been a question of disabled repos. Or should not have. yum clean all refers to cleaning all metadata, not all repos. It only operates on one single repo, be it implicit (the default link) or an explicit -r option. man yum CLEAN OPTIONS The following are the ways which you can invoke yum in clean mode. Note that all files in the commands below means all files in currently enabled repositories. If you want to also clean any (temporarily) disabled repositories you need to use --enablerepo='*' option. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
