Bug 1361424

Summary: [RFE] add cli option for clean_requirements_on_remove=no
Product: [Fedora] Fedora Reporter: Jens Petersen <petersen>
Component: dnfAssignee: Jaroslav Mracek <jmracek>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: jmracek, mluscon, packaging-team-maint, petersen, pnemade, rpm-software-management, vmukhame
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: dnf-2.6.2-1.fc26 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-07-25 16:56:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jens Petersen 2016-07-29 05:21:56 UTC
Description of problem:
Sometimes clean_requirements_on_remove is useful othertimes it is really
annoying and having to type out "--setopt=clean_requirements_on_remove=no"
is too long and hard to remember...

Could you please add a commandline option for dnf remove
like "--no-clean-reqs"?  Thanks!  This would be pretty nice IMHO.

Comment 1 Honza Silhan 2016-08-01 11:46:43 UTC
Would it be enough for you if bash autocompletion would works with config options and complete it?

We don't want to introduce CLI option for each config option. The man page would be too verbose this way. If more people request it, then it seems it's a highly demanded option and we will implement it.

Comment 2 Jens Petersen 2016-08-16 08:42:10 UTC
That would be an improvement, yes.
But I would probably just make my own alias/wrapper then:
I would not think (remember) to use --setopt for everyday dnf usage.

I still feel this one is a big change in behaviour compared to yum,
and it should be a priority to make the old behaviour more accessible/
discoverable.  As often as not I don't want the new behaviour.

Comment 3 Jaroslav Mracek 2017-06-30 11:39:40 UTC
Still interest in that option? Or the present behavior of dnf-2.5.1 do not requires to change so often the setting? Or in case you want to prevent a removal of some packages, there is a mark command (dnf mark installed <package>), that will change reason of installed package from dep to user, therefore you will get exactly what you need without any additional changes in dnf. Or is there any special reason why you don't want to mark dependencies that you want to protect as a user installed?

I ask you because:
1. The bash completion is not in good shape in DNF therefore the proposed solution is more like a wish than an option.
2. I would like to implement a solution or close the bug, but don't have enough information.
3. The bug is here for more than 10 months and no additional requester for that feature, therefore only good user-case with no work-around will favor the implementation.

Thanks a lot for additional information and feedback for dnf-2.5.1.

Comment 4 Jens Petersen 2017-07-17 22:58:26 UTC
I still think the option is useful to avoid excessive churn when removing packages.

eg I install a bunch of Haskell devel packages which also pulls in gcc, etc.
Then I update the Haskell packages to some newer experimental packages from
copr say.  Finally I want to go back to the original Fedora Haskell packages
so I remove all the Haskell packages (but then dnf makes we remove gcc etc too)
and then install the original Haskell packages again, which pulls in gcc again!
I would like a simple option not to have to download gcc and reinstall it again.

I will try playing with dnf mark next time though if I remember.

Comment 5 Jaroslav Mracek 2017-07-18 11:38:30 UTC
I created a pull request that introduce a new option --noclean that should provide requested functionality (https://github.com/rpm-software-management/dnf/pull/867). It will be very nice from you if you can confirm that this is what you want. Thanks a lot.

Comment 6 Jaroslav Mracek 2017-07-18 11:48:32 UTC
The option was renamed to --noautoremove

Comment 7 Jens Petersen 2017-07-19 05:49:08 UTC
I haven't tested but it looks good to me, thanks!

Comment 8 Fedora Update System 2017-07-24 14:52:40 UTC
libdnf-0.9.3-1.fc26 dnf-plugins-core-2.1.3-1.fc26 dnf-2.6.2-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-6f4c06b2d7

Comment 9 Fedora Update System 2017-07-25 04:27:32 UTC
dnf-2.6.2-1.fc26, dnf-plugins-core-2.1.3-1.fc26, libdnf-0.9.3-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-6f4c06b2d7

Comment 10 Fedora Update System 2017-07-25 16:56:33 UTC
dnf-2.6.2-1.fc26, dnf-plugins-core-2.1.3-1.fc26, libdnf-0.9.3-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.