Bug 1545994

Summary:	oddity regarding fedora "git-pull-request" package
Product:	[Fedora] Fedora	Reporter:	Sergio Basto <sergio>
Component:	git-extras	Assignee:	Björn Esser (besser82) <besser82>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	besser82, rpjday, sergio, tmz, vascom2
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-11-07 04:29:17 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 Sergio Basto 2018-02-16 02:50:57 UTC

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.

Comment 1 Sergio Basto 2018-02-16 03:01:37 UTC

https://github.com/tj/git-extras/issues/702

Comment 2 Sergio Basto 2018-02-16 03:06:32 UTC

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.

Comment 3 Fedora End Of Life 2018-02-20 15:22:11 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 4 Vasiliy Glazov 2018-09-07 12:26:41 UTC

Sergio,
I am think we should change package git-pull-request to something like git-github-pull-request.

Comment 5 Sergio Basto 2018-09-07 12:48:31 UTC

OK I add you as admin .

Thanks.

Comment 6 Vasiliy Glazov 2018-09-07 13:05:29 UTC

I suggested resolution in https://bugzilla.redhat.com/show_bug.cgi?id=1558167

Comment 7 Ben Cotton 2019-05-02 20:57:58 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 8 Ben Cotton 2019-05-28 22:22:09 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.