Description of problem: > > since you seem to be heavily involved with fedora packaging, a minor > oddity i just noticed ... there appears to be a separate package for > "git-pull-request": > > https://koji.fedoraproject.org/koji/packageinfo?packageID=25385 > > even as that same command is part of "git-extras": > > $ rpm -qf /usr/bin/git-pull-request > git-extras-4.4.0-2.fc27.noarch This is a packaging bug that will need to be resolved in git-extras and/or git-pull-request. Possible solutions include: - add Conflicts: - drop /usr/bin/git-pull-request from git-extras - rename /usr/bin/git-pull-request in one of the packages Neither of those are part of the git package. That can be verifued by looking at which source rpm provides the binary packages: $ dnf info git-extras git-pull-request | grep ^Source Source : git-extras-4.4.0-2.fc27.src.rpm Source : git-pull-request-2.4.0-1.fc28.src.rpm I haven't had any contact with the folks that package either of these tools and I don't use either of them myself. It's possible that the person who has packaged git-pull-request does not know about git-extras. You can see the maintainers of each package and file bugs via: https://src.fedoraproject.org/rpms/git-extras https://src.fedoraproject.org/rpms/git-pull-request Ideally, the package review process should catch these sort of things, but it's too easy to miss. There's even a checked item in the git-pull-request review that it doesn't 'generate any conflicts': https://bugzilla.redhat.com/show_bug.cgi?id=1499443 It appears that the git-extras package has provided /usr/bin/git-pull-request for numerous releases. The git-pull-request package has only been pushed to rawhide at this point. in reply I wrote: rpm -qf /usr/share/man/man1/git-pull-request.1.gz git-extras-4.4.0-1.fc26.noarch man /usr/share/man/man1/git-pull-request.1.gz git-pull-request - Create pull request for GitHub project git-pull-request from git-pull-request have anything better than the version of git-extras ? (...) after some comments : Haïkel wrote: Our main focus should be user experience, not dnf error logging. 1. renaming binaries breaks user experience as they won't be usable as git subcommands (aliases are not supported) 2. there's no use case to have both packages installed on the same machine 3. binaries are not drop-in replacement of each others 4. I'm quite sure that g-p-r author will refuse to rename the binary If we refer to the guidelines, this is a situation where Conflicts is explicitly allowed: https://fedoraproject.org/wiki/Packaging:Conflicts#Incompatible_Binary_Files_with_Conflicting_Naming_.28and_stubborn_upstreams.29 And they're will be no error from dnf about duplicated file. H.
https://github.com/tj/git-extras/issues/702
Todd argument : Haïkel wrote: >>> - rename /usr/bin/git-pull-request in one of the >>> packages >>> > > this will break workflow as this is used as a subcommand of git and git > has naming requirements for such tools. But effectively the only requirement is that it begins with git-. One of them could be renamed with a different subcommand suffix or prefix (e.g. git github-pull-request or git pull-request-github). I'm not saying I have a preference for any of these option, I was just tossing out some ideas. I don't use either of these packages, so as long as they don't cause bug reports against git itself, I don't have much concern about how this file conflict is resolved. :) Personally, I wish it were clearer when commands were added via packages outside of the upstream git, since users often can't tell that what they are using doesn't come from git itself. I wonder how many users would know that 'git request-pull' is from git and 'git pull-request' is not, for example? Perhaps git-pull-request should be named github-pull-request instead? That avoids the conflict and makes it clear that it's not a git subcommand. Nothing would stop users from creating an alias, but that would be a conscious choice of the user then.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
Sergio, I am think we should change package git-pull-request to something like git-github-pull-request.
OK I add you as admin . Thanks.
I suggested resolution in https://bugzilla.redhat.com/show_bug.cgi?id=1558167
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.
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.