Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
On 2022-05-24 21:52:55, SZ Lin (林上智) wrote: > Hi, > > Antoine Beaupré 於 2022年5月19日 週四 下午10:11寫道： >> [...] >> SZ, do you agree with removing the `gh` binary from the `gitsome` binary >> package? I'd be happy to send a NMU to do this if you agree, which would >> unblock `gh` from migrating into testing. > > Yes, please go ahead :-) Great, that's really good to hear. I'm going to make a NMU and MR this very morning to solve this. Thanks for doing the right thing! -- Premature optimization is the root of all evil - Donald Knuth
Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
Hi, Antoine Beaupré 於 2022年5月19日 週四 下午10:11寫道： > > On 2022-02-27 10:09:32, Paul Wise wrote: > > Control: forwarded -1 https://github.com/donnemartin/gitsome/issues/177 > > > > On Sat, 26 Feb 2022 23:43:14 +0800 SZ Lin (林上智) wrote: > > > >> The "gitsome" has used "gh" since 2017, and thus would you mind renaming > >> the "gh" in your package to avoid the conflict issue? > > > > Since gh is the official GitHub client, probably it should retain "gh" > > and gitsome should move to "git some" or similar, as I have suggested > > in the above upstream issue. The only commentor there agreed with me. > > And I agree with you. The gitsome package already installs two binaries: > one is called "gh" and the other is called "gitsome". It seems to me it > could simply drop the "gh" alias and none would be the worse. > > SZ, in your February 26 message[1], you explicitly asked the gh package > maintainers to rename their package, which was refused. It seems the > concensus that has developped in the following thread is that it is > instead your package, gitsome, that should have its binary renamed. > > Pabs suggested `gitsome` could also be renamed to `git-some` which would > make it visible as a `git some` subcommand, from what I understand. It > seems like the `gh` alias is kind of an alias unrelated with the main > functionality of the package. > > SZ, do you agree with removing the `gh` binary from the `gitsome` binary > package? I'd be happy to send a NMU to do this if you agree, which would > unblock `gh` from migrating into testing. Yes, please go ahead :-) > > Otherwise, how can we reach consensus on this? The policy says that if > we can't reach consensus, *both* packages need to be renamed, and that > seems like a situation where we would all lose. > > I'll also point out that the upstream issue hasn't seen any activity > since pabs commented on it in February, so it doesn't seem like we can > count on upstream to fix this for us. The issue has been open for 2 > years now. Yeah, it seems like the upstream is inactive somehow. SZ > > Thank you for your time! > > [1]: > https://lists.debian.org/msgid-search/CAFk6z8Mw0kFHehm_a7=0bmdt6mzff03sewx+y93xy42bkq7...@mail.gmail.com > > -- > Tu connaîtras la vérité de ton chemin à ce qui te rend heureux. > - Aristote >
Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
On 2022-02-27 10:09:32, Paul Wise wrote: > Control: forwarded -1 https://github.com/donnemartin/gitsome/issues/177 > > On Sat, 26 Feb 2022 23:43:14 +0800 SZ Lin (林上智) wrote: > >> The "gitsome" has used "gh" since 2017, and thus would you mind renaming >> the "gh" in your package to avoid the conflict issue? > > Since gh is the official GitHub client, probably it should retain "gh" > and gitsome should move to "git some" or similar, as I have suggested > in the above upstream issue. The only commentor there agreed with me. And I agree with you. The gitsome package already installs two binaries: one is called "gh" and the other is called "gitsome". It seems to me it could simply drop the "gh" alias and none would be the worse. SZ, in your February 26 message[1], you explicitly asked the gh package maintainers to rename their package, which was refused. It seems the concensus that has developped in the following thread is that it is instead your package, gitsome, that should have its binary renamed. Pabs suggested `gitsome` could also be renamed to `git-some` which would make it visible as a `git some` subcommand, from what I understand. It seems like the `gh` alias is kind of an alias unrelated with the main functionality of the package. SZ, do you agree with removing the `gh` binary from the `gitsome` binary package? I'd be happy to send a NMU to do this if you agree, which would unblock `gh` from migrating into testing. Otherwise, how can we reach consensus on this? The policy says that if we can't reach consensus, *both* packages need to be renamed, and that seems like a situation where we would all lose. I'll also point out that the upstream issue hasn't seen any activity since pabs commented on it in February, so it doesn't seem like we can count on upstream to fix this for us. The issue has been open for 2 years now. Thank you for your time! [1]: https://lists.debian.org/msgid-search/CAFk6z8Mw0kFHehm_a7=0bmdt6mzff03sewx+y93xy42bkq7...@mail.gmail.com -- Tu connaîtras la vérité de ton chemin à ce qui te rend heureux. - Aristote
Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
Hi, On 23-03-2022 12:32, Jonas Smedegaard wrote: Quoting Anthony Fok (2022-03-23 11:08:36) Rather than keeping this "Serious" bug open and keeping both gitsome and gh out of Debian testing, I think the simple solution of having gh "Conflicts: gitsome", which is one of the option specified in https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts, would suffice for now, allowing both packages to (re-)enter testing in the meantime. SZ, if you think the use of alternatives (such that both the gitsome and gh packages can be installed simultaneously) is a better solution, I'd be happy to work something out with you too. Please note that above Policy section covers only the functionality of that packaging hint, not its suitability. It is my understanding that both that specific use of Conflicts and the use of alternatives is only acceptable for executables providing same or at least largely overlapping) ABI. Do gitsome and gh provide same or quite similar ABI? It was already quoted in the bug report, policy is pretty clear (emphasis mine) (yes, I *suspect* that /usr/bin/gh does something quite different from reading the package descriptions): """ 10.1. Binaries Two different packages *must not* install programs with different functionality but with *the same filenames*. (The case of two programs having the same functionality but different implementations is handled via “alternatives” or the “Conflicts” mechanism. See Maintainer Scripts and Conflicting binary packages - Conflicts respectively.) If this case happens, one of the programs must be renamed. The maintainers should report this to the debian-devel mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, both programs must be renamed. """ Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
Quoting Anthony Fok (2022-03-23 11:08:36) > Rather than keeping this "Serious" bug open and keeping both gitsome > and gh out of Debian testing, I think the simple solution of having gh > "Conflicts: gitsome", which is one of the option specified in > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts, > would suffice for now, allowing both packages to (re-)enter testing in > the meantime. > > SZ, if you think the use of alternatives (such that both the gitsome > and gh packages can be installed simultaneously) is a better solution, > I'd be happy to work something out with you too. Please note that above Policy section covers only the functionality of that packaging hint, not its suitability. It is my understanding that both that specific use of Conflicts and the use of alternatives is only acceptable for executables providing same or at least largely overlapping) ABI. Do gitsome and gh provide same or quite similar ABI? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
Hi everyone, On Sat, Feb 26, 2022 at 7:09 PM Paul Wise wrote: > > Control: forwarded -1 https://github.com/donnemartin/gitsome/issues/177 > > On Sat, 26 Feb 2022 23:43:14 +0800 SZ Lin (林上智) wrote: > > > The "gitsome" has used "gh" since 2017, and thus would you mind renaming > > the "gh" in your package to avoid the conflict issue? > > Since gh is the official GitHub client, probably it should retain "gh" > and gitsome should move to "git some" or similar, as I have suggested > in the above upstream issue. The only commentor there agreed with me. Thank you all for the discussion and attempt at resolving the filename conflict. Judging from gitsome's GitHub repo being left stagnant since May 2019, with Issues and PRs unanswered, despite the fact that upstream author is still active daily on GitHub, I doubt we'll see a reply from gitsome's author anytime soon. Automation scripts are relying on the GitHub CLI command to be named as "gh", so renaming /usr/bin/gh in "gh" to something else is out of the question too. Rather than keeping this "Serious" bug open and keeping both gitsome and gh out of Debian testing, I think the simple solution of having gh "Conflicts: gitsome", which is one of the option specified in https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts, would suffice for now, allowing both packages to (re-)enter testing in the meantime. SZ, if you think the use of alternatives (such that both the gitsome and gh packages can be installed simultaneously) is a better solution, I'd be happy to work something out with you too. Cheers, Anthony
Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
Control: forwarded -1 https://github.com/donnemartin/gitsome/issues/177 On Sat, 26 Feb 2022 23:43:14 +0800 SZ Lin (林上智) wrote: > The "gitsome" has used "gh" since 2017, and thus would you mind renaming > the "gh" in your package to avoid the conflict issue? Since gh is the official GitHub client, probably it should retain "gh" and gitsome should move to "git some" or similar, as I have suggested in the above upstream issue. The only commentor there agreed with me. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
Hi, gh package maintainer Axel Beckert 於 2022年2月16日 週三 下午2:15寫道： > Package: gh,gitsome > Severity: serious > Control: found -1 gitsome/0.8.0+ds-6 > Control: found -1 gh/2.4.0+dfsg1-1 > > Hi, > > installing gh fails for me as follows: > > Unpacking gh (2.4.0+dfsg1-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-DkqFj5/24-gh_2.4.0+dfsg1-1_amd64.deb (--unpack): > trying to overwrite '/usr/bin/gh', which is also in package gitsome > 0.8.0+ds-6 > According to the Debian policy [1], "the two different packages must not install programs with different functionality but with the same filenames. ... If this case happens, one of the programs must be renamed." [1] https://www.debian.org/doc/debian-policy/ch-files.html#s-binaries The "gitsome" has used "gh" since 2017, and thus would you mind renaming the "gh" in your package to avoid the conflict issue? I would appreciate it if you could consider my request, and feel free to let me know if you have another proposal. Regards, SZ > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (990, 'unstable'), (600, 'testing'), (500, > 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, > 'experimental-debug'), (1, 'buildd-experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > LSM: AppArmor: enabled >
Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
Package: gh,gitsome Severity: serious Control: found -1 gitsome/0.8.0+ds-6 Control: found -1 gh/2.4.0+dfsg1-1 Hi, installing gh fails for me as follows: Unpacking gh (2.4.0+dfsg1-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-DkqFj5/24-gh_2.4.0+dfsg1-1_amd64.deb (--unpack): trying to overwrite '/usr/bin/gh', which is also in package gitsome 0.8.0+ds-6 -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled
