Bug 1330211 - RFE: dnf clean does not respect enablerepo/disablerepo anymore
Summary: RFE: dnf clean does not respect enablerepo/disablerepo anymore
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 28
Hardware: Unspecified
OS: Unspecified
low
high
Target Milestone: ---
Assignee: Jaroslav Rohel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1423399 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-25 15:57 UTC by Patrick Monnerat
Modified: 2019-05-28 23:20 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-28 23:20:15 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Patrick Monnerat 2016-04-25 15:57:39 UTC
Description of problem:
Old version of dnf (as well as yum) used to support:
   dnf --disablerepo=* --enablerepo=somerepo clean all
To clean a single repository's files/caches, etc.

Current version ignores these options a wipe everything.


Version-Release number of selected component (if applicable):
dnf-1.1.8-1

How reproducible:
Always

Steps to Reproduce:
1. dnf --disablerepo=* --enablerepo=updates clean all
2. dnf update


Actual results:
Fedora 23 - x86_64                              203 kB/s |  43 MB     03:36    
Fedora 23 - x86_64 - Updates                    775 kB/s |  21 MB     00:28

(the fedora repository is reloaded: 3m30 and 43Mb lost)


Expected results:
Fedora 23 - x86_64 - Updates                    775 kB/s |  21 MB     00:28

(only the update repository gets refreshed).

Comment 1 Honza Silhan 2016-05-02 11:20:48 UTC
Yep, it's the new feature. See bug 1278225.

Comment 2 Patrick Monnerat 2016-05-02 13:30:53 UTC
Thanks for the reply.
Although I understand the bug 1278225 is a reason for change, I rather consider this as a "lack of feature".
Can't we imagine to revert to the previous behavior if --disablerepo and/or --enablerepo are specified as command argument ? This will be a precious feature back.
Thanks for considering it.

Comment 3 J. Randall Owens 2016-05-20 00:40:34 UTC
Maybe there's something to be said for it when "clean all", but it seems hard to justify this for "clean metadata" and other more specific forms of clean, the ones that explicitly aren't "all".

Comment 4 Michael Mráka 2017-02-17 10:36:48 UTC
*** Bug 1423399 has been marked as a duplicate of this bug. ***

Comment 5 Pavel Raiskup 2017-02-17 12:36:50 UTC
Michael, please describe how this is related to bug 1278225, thanks.  This
is serious regression; I used this feature on daily basis (unless I did it
a bad way).

Also, do we have a work-around for use-case described in duplicate bug
1423399?  Can I adjust somehow 'metadata_expire' argument for one
repository only (without touching the yum config file)?  Thanks.

Comment 6 Michael Mráka 2017-02-17 14:00:47 UTC
(In reply to Pavel Raiskup from comment #5)
> Michael, please describe how this is related to bug 1278225, thanks.  This
> is serious regression; I used this feature on daily basis (unless I did it
> a bad way).

In bug 1278225 we intentionally changed clean command to erase cache for all repos. This bug complains about new behaviour. So its related.

> Also, do we have a work-around for use-case described in duplicate bug
> 1423399?  Can I adjust somehow 'metadata_expire' argument for one
> repository only (without touching the yum config file)?  Thanks.

dnf --setopt=myreponame.metadata_expire=1

Comment 7 Pavel Raiskup 2017-02-17 14:15:58 UTC
Sounds like working way around, so it works for me, thanks!

Using together with --enable/disable-repo should be almost equivalent.
I.e., is this really doing 'clean all' for 'myreponame'?

Comment 8 Honza Silhan 2017-02-20 16:20:34 UTC
We might consider adding another option to trigger theold "clean all" behavior.

Comment 9 Patrick Monnerat 2017-02-20 16:23:25 UTC
> We might consider adding another option to trigger theold "clean all" behavior.
+1
In addition, this should not be limited to "all".

Comment 10 Jaroslav Rohel 2017-10-16 08:54:18 UTC
PR: https://github.com/rpm-software-management/dnf/pull/921

Comment 11 Jan Kurik 2018-05-31 09:12:14 UTC
This bug is currently reported against a Fedora version which is already unsuported.
I am changing the version to '27', the latest supported release.

Please check whether this bug is still an issue on the '27' release.
If you find this bug not being applicable on this release, please close it.

Comment 12 Jens Petersen 2018-07-25 03:14:41 UTC
IF you are going to ignore --{enable,disable}-repo, there should at least be a warning to that effect...

Comment 13 Jens Petersen 2018-07-25 03:27:05 UTC
The best would be to have something like:

dnf clean metadata --only-repo=myrepo

Comment 14 Ben Cotton 2019-05-02 20:16:06 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 15 Ben Cotton 2019-05-28 23:20:15 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.