Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
22 views
Skip to first unread message
Axel Beckert
Feb 16, 2022, 1:20:03 AM2/16/22
to
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
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
SZ Lin
Feb 26, 2022, 10:50:04 AM2/26/22
to
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."
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
Paul Wise
Feb 26, 2022, 9:20:04 PM2/26/22
to
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
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?
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
Jonas Smedegaard
Mar 23, 2022, 7:40:03 AM3/23/22
to
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
> 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
Antoine Beaupré
May 19, 2022, 10:20:04 AM5/19/22
to
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=0bmdT6mzff03sEW...@mail.gmail.com
--
Tu connaîtras la vérité de ton chemin à ce qui te rend heureux.
- Aristote
SZ Lin (林上智)
May 24, 2022, 10:20:03 AM5/24/22
to
Hi,
Antoine Beaupré <ana...@debian.org> 於 2022年5月19日 週四 下午10:11寫道：
>
> 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
Antoine Beaupré <ana...@debian.org> 於 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 :-)
> 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.
SZ
Antoine Beaupré
May 24, 2022, 11:00:03 AM5/24/22
to
On 2022-05-24 21:52:55, SZ Lin (林上智) wrote:
> Hi,
>
> Antoine Beaupré <ana...@debian.org> 於 2022年5月19日 週四 下午10:11寫道：
>>
[...]
> Hi,
>
> Antoine Beaupré <ana...@debian.org> 於 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 :-)
very morning to solve this.
Thanks for doing the right thing!
--
Premature optimization is the root of all evil
- Donald Knuth
Antoine Beaupre
May 24, 2022, 2:40:04 PM5/24/22
to
Control: tags 1005858 + patch
Control: tags 1005858 + pending
Dear maintainer,
I've prepared an NMU for gitsome (versioned as 0.8.0+ds-7.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
I have also pushed this patch to GitLab, but haven't pushed a tag in
case we want to revert.
Regards.
Control: tags 1005858 + pending
Dear maintainer,
I've prepared an NMU for gitsome (versioned as 0.8.0+ds-7.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
I have also pushed this patch to GitLab, but haven't pushed a tag in
case we want to revert.
Regards.
Antoine Beaupré
May 24, 2022, 2:50:03 PM5/24/22
to
On 2022-05-24 14:32:45, Antoine Beaupre wrote:
> Control: tags 1005858 + patch
> Control: tags 1005858 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for gitsome (versioned as 0.8.0+ds-7.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
Sigh. I actually messed up and forgot to pass --delayed=2 to
> Control: tags 1005858 + patch
> Control: tags 1005858 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for gitsome (versioned as 0.8.0+ds-7.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
dput. I realized to late to cancel.
I hope it's still okay...
a.
--
We must learn to live together as brothers or perish together as fools.
- Martin Luther King, Jr.
SZ Lin
May 25, 2022, 10:20:04 AM5/25/22
to
Hi,
Antoine Beaupré <ana...@debian.org> 於 2022年5月25日 週三 上午2:45寫道：
Thank you very much for your contribution :-)
SZ
Antoine Beaupré <ana...@debian.org> 於 2022年5月25日 週三 上午2:45寫道：
>
> On 2022-05-24 14:32:45, Antoine Beaupre wrote:
> > Control: tags 1005858 + patch
> > Control: tags 1005858 + pending
> >
> > Dear maintainer,
> >
> > I've prepared an NMU for gitsome (versioned as 0.8.0+ds-7.1) and
> > uploaded it to DELAYED/2. Please feel free to tell me if I
> > should delay it longer.
>
> Sigh. I actually messed up and forgot to pass --delayed=2 to
> dput. I realized to late to cancel.
>
> I hope it's still okay...
No worries.
> On 2022-05-24 14:32:45, Antoine Beaupre wrote:
> > Control: tags 1005858 + patch
> > Control: tags 1005858 + pending
> >
> > Dear maintainer,
> >
> > I've prepared an NMU for gitsome (versioned as 0.8.0+ds-7.1) and
> > uploaded it to DELAYED/2. Please feel free to tell me if I
> > should delay it longer.
>
> Sigh. I actually messed up and forgot to pass --delayed=2 to
> dput. I realized to late to cancel.
>
> I hope it's still okay...
Thank you very much for your contribution :-)
SZ
0 new messages