The git package is split into git and git-core. The later allows to remove the perl dependency by forgoing a few git plugins that use perl. It should be possible to remove the git package (and the perl stack too) without removing git-core packages and hence keep core git functionality. $ rpm -e git error: Failed dependencies: git = 2.5.0-1.fc23 is needed by (installed) perl-Git-2.5.0-1.fc23.noarch $ $ dnf remove git Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: git armv7hl 2.5.0-1.fc23 @fedora 343 k git-core armv7hl 2.5.0-1.fc23 @fedora 15 M git-core-doc armv7hl 2.5.0-1.fc23 @fedora 11 M perl-Git noarch 2.5.0-1.fc23 @fedora 57 k Transaction Summary ================================================================================ Remove 4 Packages Installed size: 26 M Is this ok [y/N]: I believe the git auto dep cleanup is being incorrectly too smart, git-core has binaries (like the main 'git' binary) that are useful on their own.
Please see http://dnf.readthedocs.org/en/latest/command_ref.html#mark-command-label or you can temporarily disable clean_requirements_on_remove (from cmd line by --setopt=<option>=<value>).
(In reply to Michal Luscon from comment #1) > Please see > http://dnf.readthedocs.org/en/latest/command_ref.html#mark-command-label or > you can temporarily disable clean_requirements_on_remove (from cmd line by > --setopt=<option>=<value>). How does that work in kickstarts, or automated build platforms? I've seen the mark stuff, it looks like a hack to me and I don't see how it can be used automatically in automation systems
I am not sure that we are on the same page. Could you please elaborate more what kind of issues you expect in kickstarts and automated build platforms?
(In reply to Michal Luscon from comment #3) > I am not sure that we are on the same page. Could you please elaborate more > what kind of issues you expect in kickstarts and automated build platforms? I'll need some time to create you some kickstart use cases. But either way this cleanup functionality is broken, and "mark" is just a hack to work around this issue. package-cleanup use to suggest removal of libraries that no longer had dependencies, but if there's were standalone binaries in /bin /usr/bin etc it would leave it because it's still usable on it's own capabilities, as is the case with git-core.
Ok, I see your point. Unfortunately, there are two valid use cases: #1 I want to remove git with all dependencies to not use git any more. #2 I want to remove git and preserve some of its dependencies which I consider useful. => there should exists some way how to differentiate between those two and that way is dnf mark. I admit that the mark command is a rather technocratic solution, but we decided to preserve syntax which users are already familiar with (group mark). On the other side, I strongly believe that #1 is far more common use case than #2 and if you don't like autoremove in general, you can easily turn it off from config file.
(In reply to Michal Luscon from comment #5) > Ok, I see your point. > > Unfortunately, there are two valid use cases: > > #1 I want to remove git with all dependencies to not use git any more. > #2 I want to remove git and preserve some of its dependencies which I > consider useful. #3 I don't want git (the package) but I do want git-core and I don't want dnf to double think for me (IE I want to be able to specify it during install (say a kickstart) and not have dnf clean it up later. dnf mark is not the fix to that problem. Am I suppose to run a series of "dnf mark" shit in post install scripts just in the hope that dnf won't clean it up later? What if stuff changes later? yum/package-cleanup managed to deal with this just fine by deciding if a package was purely a library (and hence useless on it's own if nothing depended on it) or whether it had some other value such as binaries in /bin /usr/bin /sbin etc....
I mean if it was say git-libs (not that there is exactly that, and not to be confused with libgit2) and nothing else referenced it I can completely understand removing it. I see the mark command as a useful command for a desktop env to work around something like the removal of say a media codec but it can't be used as a means to cover up other completely flawed decisions and a not a proper understanding of other use cases.
> #3 I don't want git (the package) but I do want git-core and I don't want > dnf to double think for me (IE I want to be able to specify it during > install (say a kickstart) and not have dnf clean it up later. So why do you install git at all and not just git-core? Deciding if a package is purely a library isn't double thinking for you?
> I see the mark command as a useful command for a desktop env to work around > something like the removal of say a media codec but it can't be used as a > means to cover up other completely flawed decisions and a not a proper > understanding of other use cases. That's the reason why I asked you for your usecase, so let's wait for the specification.
Feel free to reopen when you supply requested usecase.