Bug 1276917 - dnf incorrectly tries to remove git-core when removing git package
dnf incorrectly tries to remove git-core when removing git package
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-01 04:45 EST by Peter Robinson
Modified: 2015-11-09 07:18 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-09 07:18:13 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Robinson 2015-11-01 04:45:27 EST
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.
Comment 1 Michal Luscon 2015-11-02 10:46:44 EST
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>).
Comment 2 Peter Robinson 2015-11-02 11:24:37 EST
(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
Comment 3 Michal Luscon 2015-11-03 05:23:52 EST
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?
Comment 4 Peter Robinson 2015-11-03 05:52:33 EST
(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.
Comment 5 Michal Luscon 2015-11-03 09:05:58 EST
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.
Comment 6 Peter Robinson 2015-11-03 09:11:29 EST
(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....
Comment 7 Peter Robinson 2015-11-03 09:15:02 EST
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.
Comment 8 Michael Mráka 2015-11-03 09:26:22 EST
> #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?
Comment 9 Michal Luscon 2015-11-03 09:42:32 EST
> 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.
Comment 10 Michal Luscon 2015-11-09 07:18:13 EST
Feel free to reopen when you supply requested usecase.

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