NEW queueOn Sun, Aug 15, 2021 at 10:45 PM Brian Thompson
<br...@hashvault.io> wrote:
* * >
> On Sat, 14 Aug 2021 14:18:34 -0400 Antoine Beaupré wrote:
> >
> > It's not on the package name, but there's already a clash on the
> > binary name, which we should be mindful of:
> > gitsome provides direct integration with GitHub and GitHub Enterprise
> > in a terminal.
> >
> > Since it's a git (and github, even!) related tool, we might even want
> > to Conflict with it directly...
>
> Since there is already a package that uses that binary name, who should
> change it? Do we follow a first-come first-serve binary name reservation
> strategy? I don't think it's a big deal to change the name.
>
> I'm not sure what to rename it to. I don't like binaries with long,
> descriptive names, but I don't know what we could use that is short. I
> will raise awareness about this issue with the upstream developers.
Hi Brian,
First of all, thank you for volunteering to help with the packaging of
GitHub CLI.
Here is my understanding:
1. We may name the Debian source and binary package as "gh"
(same as how upstream names it in https://github.com/cli/cli/releases),
though the consensus here leans toward naming the package "github-cli".
2. Even though both "gitsome" and the new "github-cli" package contain
/usr/bin/gh, and since they both perform somewhat similar functions,
we can assume that an end user would only want to install one of them,
hence the suggestion that we set "Conflicts: gitsome" in debian/control
of "github-cli". (We _could_ go with the dpkg-divert(1) route, but I don't
think that is worth the effort unless there were demand, i.e. if someone
were to report a bug about it.)
3. > Do we follow a first-come first-serve binary name reservation
> strategy?
A: No, not necessary, especially seeing how gitsome development
seems to have stopped in May 2019 according to
https://github.com/donnemartin/gitsome , whereas GitHub CLI
is actively being developed, with the most recent commit being
merely 10 hours ago.
4. Paul Wise's suggestion of adding "Provides: gh" is a good idea
so that end users looking for github-cli can simply run
"apt install gh" and apt will install "github-cli" for them.
Furthermore, this should help the end users who have installed
upstream's "gh" deb package to seamlessly migrate to Debian's
official "github-cli" package. (probably needs "Replaces: gh" too)
So, in summary, it just means the following in debian/control:
Source: github-cli
...
XS-Go-Import-Path: github.com/github/cli
...
Package: github-cli
...
Conflicts: gitsome, gh
Provides: gh
Replaces: gh
(All ye experts here, please correct me if you spot any errors,
especially I am always confused about Conflicts, Provides, Replaces
and Breaks and may have gotten it wrong.)
Now, you might run into a problem when actually trying to name the
package "github-cli" (or even "gh") because dh-make-golang 0.4.0 does
not allow for overriding the package name. For example:
dh-make-golang -type p -pristine-tar github.com/cli/cli
would name the package "cli"... I am working on packaging the latest
dh-make-golang and will try to add a flag to allow overriding the
package name, to be uploaded as dh-make-golang 0.4.1 or 0.5.0.
Then there are the yet-to-be-packaged dependencies. Just so that you
know, the following packages that github-cli depends on have already
been packaged but currently sitting in the
https://ftp-master.debian.org/new.html NEW queue:
* golang-github-yuin-goldmark-emoji 1.0.1-1
* golang-github-muesli-reflow 0.3.0-1
* golang-github-shurcool-graphql 0.0~git20200928.18c5c31-1
* golang-github-shurcool-githubv4 0.0~git20210725.83ba7b4-1
I'll report back here if I were to package and upload more of these
dependencies so as to avoid duplication of work.
Cheers,
Anthony
