Bug#951374: RFP: gh -- the GitHub CLI
Hi Brian, Sorry for the late reply. On Mon, Aug 16, 2021 at 10:56 PM Brian Thompson wrote: > On Mon, 2021-08-16 at 21:27 -0600, Anthony Fok wrote: > > > > 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. > > It sounds like this functionality is required for what we are trying to > achieve. > I am not very familiar with the golang family and its surrounding > infrastructure > regarding Debian. Perhaps I am not best-equipped to package the github-cli > tool, > but I am always willing to learn. That's awesome! Welcome to the Debian Go Packaging Team! You may start by taking a look at https://go-team.pages.debian.net/ . I am happy to report that dh-make-golang 0.5.0-1 has been uploaded, which means now you can name the package "gh" (to match the name of the Debian package provided upstream on GitHub) by using the following command: dh-make-golang -pristine-tar -program_package_name gh github.com/cli/cli (the -pristine-tar option is just my personal preference and is optional.) > > 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 Hurray! These 4 packages have entered Debian! (Thanks to FTP Masters!) > > I'll report back here if I were to package and upload more of these > > dependencies so as to avoid duplication of work. > It sounds like we should pause the github-cli technical packaging work until > dependent features and packages are added to the ecosystem. Would you agree > with > that? I'm not seeing any BTS tags specific to RFPs (or bugs in general) for > marking it as "blocked", as we would say in the corporate world. Although I am > not sure that is even necessary. Well, we won't know what the dependencies are until we start packaging gh, so we would start by running dh-make-golang which will give us more information such as the yet-to-be-packaged dependencies. Yes, it would be a good idea to mark the relevant ITP/RFP bugs as blocking for gh. Not strictly necessary, but definitely helpful to have the ITP/RFP bugs connected to this bug, otherwise it is hard to keep track of them. So yes, with the new dh-make-golang 0.5.0, you can start packaging gh and its dependencies any time now! Make sure to double check the NEW queue and WNPP to ensure you are not doing work that has already been done by others. :-) Let's begin! Cheers, Anthony
Bug#951374: RFP: gh -- the GitHub CLI
On 2021-08-18 05:33:30, Anthony Fok wrote: > Hi Antoine, > > On Tue, Aug 17, 2021 at 7:40 AM Antoine Beaupré wrote: >> >> On 2021-08-16 21:27:33, Anthony Fok wrote: >> >> [...] >> >> > 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 >> >> I do not see why you would Conflicts with `gh` here. It's not an actual >> package name, so it doesn't need that. I am not sure that Replaces is >> necessary either. Those would be required if we were renaming or >> replacing an existing package, which is not quite the case here. > > That is because "gh" _is_ an actual Debian package name > albeit not from official Debian sources. > That is how GitHub has named their .deb packages, as seen in their > latest release page here: > > https://github.com/cli/cli/releases/tag/v1.14.0 > > As a matter of fact, I already have their GoRelease-generated > gh_1.14.0_linux_arm64.deb installed because I couldn't wait. :-) > Needed it for a work task at > https://github.com/OpenDRR/opendrr-platform/issues/126 > > Anyhow, since GitHub has already named their deb package "gh", it may > be a good argument for us to name our official Debian package as "gh" > too. (haha!) > > But anyhow, if we do decide to name our package "github-cli", the > "Conflicts: gh" would allow me to smoothly upgrade from GitHub's "gh" > deb package to Debian's "github-cli" deb package. Oh, good point. This does seem like a good migration path then, although I can't help but think we should collaborate with upstream in this case, to make sure we converge over something instead of creating a confusing pair of package names. It would be better for our users to have a consistent naming with upstream... >> Some would argue that installing gitsome *and* gh *would* be desirable, >> however, which might make the Conflicts problematic. If that's the case, >> then there is a number of mechanisms that we could use, but I'd actually >> cross that bridge when we get there. > > Totally agreed. > I find diversions somewhat messy, so I'd rather not go there > unless someone actually starts complaining. :-) Right, I would totally avoid diversions in general. I was thinking more of "alternatives", and/or maybe splitting "gh" out of gitsome so that it wouldn't have to conflict anymore. a. -- Treating different things the same can generate as much inequality as treating the same things differently. - Kimberlé Crenshaw
Bug#951374: RFP: gh -- the GitHub CLI
Hi Antoine, On Tue, Aug 17, 2021 at 7:40 AM Antoine Beaupré wrote: > > On 2021-08-16 21:27:33, Anthony Fok wrote: > > [...] > > > 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 > > I do not see why you would Conflicts with `gh` here. It's not an actual > package name, so it doesn't need that. I am not sure that Replaces is > necessary either. Those would be required if we were renaming or > replacing an existing package, which is not quite the case here. That is because "gh" _is_ an actual Debian package name albeit not from official Debian sources. That is how GitHub has named their .deb packages, as seen in their latest release page here: https://github.com/cli/cli/releases/tag/v1.14.0 As a matter of fact, I already have their GoRelease-generated gh_1.14.0_linux_arm64.deb installed because I couldn't wait. :-) Needed it for a work task at https://github.com/OpenDRR/opendrr-platform/issues/126 Anyhow, since GitHub has already named their deb package "gh", it may be a good argument for us to name our official Debian package as "gh" too. (haha!) But anyhow, if we do decide to name our package "github-cli", the "Conflicts: gh" would allow me to smoothly upgrade from GitHub's "gh" deb package to Debian's "github-cli" deb package. > Some would argue that installing gitsome *and* gh *would* be desirable, > however, which might make the Conflicts problematic. If that's the case, > then there is a number of mechanisms that we could use, but I'd actually > cross that bridge when we get there. Totally agreed. I find diversions somewhat messy, so I'd rather not go there unless someone actually starts complaining. :-) Cheers, Anthony
Bug#951374: RFP: gh -- the GitHub CLI
On 2021-08-16 21:27:33, Anthony Fok wrote: [...] > 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 I do not see why you would Conflicts with `gh` here. It's not an actual package name, so it doesn't need that. I am not sure that Replaces is necessary either. Those would be required if we were renaming or replacing an existing package, which is not quite the case here. Some would argue that installing gitsome *and* gh *would* be desirable, however, which might make the Conflicts problematic. If that's the case, then there is a number of mechanisms that we could use, but I'd actually cross that bridge when we get there. a. -- C'est la nuit qu'il est beau de croire à la lumière - Edmond Rostand
Bug#951374: RFP: gh -- the GitHub CLI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, 2021-08-16 at 21:27 -0600, Anthony Fok wrote: > NEW queueOn Sun, Aug 15, 2021 at 10:45 PM Brian Thompson > wrote: > > > > 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. > Anthony, Thank you for being intimate with the details. > Here is my understanding: > > 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. It sounds like this functionality is required for what we are trying to achieve. I am not very familiar with the golang family and its surrounding infrastructure regarding Debian. Perhaps I am not best-equipped to package the github-cli tool, but I am always willing to learn. > 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. > It sounds like we should pause the github-cli technical packaging work until dependent features and packages are added to the ecosystem. Would you agree with that? I'm not seeing any BTS tags specific to RFPs (or bugs in general) for marking it as "blocked", as we would say in the corporate world. Although I am not sure that is even necessary. - -- Best regards, Brian T. -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEbQYcTHGJyaWFuQGhh c2h2YXVsdC5pbwAKCRCDDY1y7c2GfaNpEACgqGGp/BsUjnGpALGzNbMtqY2P4b3d EqhxUmQdEzDPKw7g4ajyYkFiDm9Djgvz2g3R6jgYcjuOlcjeI3YOZNtJMmriUw7p CM4jgaaXn/YvKFQxqNWD7GTsWlJnej4mCmebiRTseG3MX8BEHb4Ukndiy3pR2vXx nhHVq+JJZsti8goTcROgToG8a0lH+rUj8yc0uN/e2JQcLCHOjXZdgUDQQzUVW+3C iVMJ1tp88vrTpXn04TxMdHIyGbWh8SMFv9Q3+F4HyWBc9UiYq4kmOw1US/0YL8PQ rwiGXzNxS6BoYZ9W0EtRwy27asBJDpfRsGOFzqzVK+fSGk7teThL3sS8SoxR1XjQ Z7sebgTsY+A0b8+YYR8UOZb1Ei616cmD/m2bKntHQHzTMQw1rmWJgKxeoh9ARv91 b1PUbZndsSDbOukj+nt+gD+NayAwJDceTYZ3hm5FnE4tADPWCkeSixQVBafNM1i5 ZY02qCqtP0Z37lRsAOj53jTweOmSm4Fv5sJG/FtqHEAnd/fNd17KT5ggii6uPEhD vdyBdtlB5K8ZboT7f2HtHuoOkAHcLPKU6rq0kAI+43Dt0nw4XTSWoB3AH2dNW4ii wKqxgOKo4j+mxc6TZckn4xNbRXrB1dGEwu7/HuRg//+EsdqNW0PWNEqpNxIRNHgz NhR8XUSX3KW71Q== =Bui2 -END PGP SIGNATURE-
Bug#951374: RFP: gh -- the GitHub CLI
NEW queueOn Sun, Aug 15, 2021 at 10:45 PM Brian Thompson 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
Bug#951374: RFP: gh -- the GitHub CLI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 14 Aug 2021 14:18:34 -0400 =?utf-8?Q?Antoine_Beaupr=C3=A9?= < anar...@orangeseeds.org> 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. - -- Best regards, Brian T. -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEZ7NQTHGJyaWFuQGhh c2h2YXVsdC5pbwAKCRCDDY1y7c2GfeX5EAChFZ4pCKTj1uvCuyAxCzr12dfdfIqC U27Bc1UwT5DAKs9T2EjihTkhstinwN3ZKLmOOznH1+lnmbdlXccYRtV4BZvu3diD iyzP4t+5voLnxViYzO8WjHcxSlA7qNUY1/16nmOuTvrNmpaxS/54gjOyFXjdOWVc CGCHUm2TG3aMTaW+OfOizBG+T+ThNNrkRg/8cKStgcR2vB8gwa/gJdT4qccsLCHv ufrxVg3p7VzjVvBD7W4Z5uczqwnYR7/3FK3M65FH1TKZTCxDIv3BYGKIIEM0nXnJ sLzFCucItVVi/Cc7CJf/sH9T49BzVfL+GTGFbDhue70+NpfOa++z7p22qq211Zvd 5E2vRXSLpQVmMY8QZy8+xDgBvi1CP1hBx98XbSE1RquV902naHowsFxTa4nkAPiK nYU81R8TbLGwdPUXO/SgnSLQ9IlA7IotwfXmEhPAge8rYIR+2TtE0Da6ROeT8Tj4 lDiH9p6RS78Y49wihatMkpxKNkypQdUwq5AZb8p3b2j/h7hFz6l9m0TcAxxkggjZ HPFDt0n0hGr6KzAtemFMP04OyqurMVCEtwn84ySmUI3Sy9i42uT36c2M7+TOd2iu C2R/kXr7ZJ9fWxwpAkyv4/4rPqu2AwSeCluzUPRLTxR/8zqlTIwGK3tDlNQH3bQD aTB5+YZvyIHIeg== =YHqO -END PGP SIGNATURE-
Bug#951374: RFP: gh -- the GitHub CLI
On 0814, Paul Wise wrote: > >Could also add a Provides: gh so it is installable with the short name. > >I would definitely like to have this in Debian, but can't help with it. > This would be ideal. Is there any benefit of renaming the package to something other than "gh"? I can help with this during the next week. -- Best regards, Brian T signature.asc Description: PGP signature
Bug#951374: RFP: gh -- the GitHub CLI
On 2021-08-08 10:17:06, Brian Thompson wrote: >> I personally find that "gh" is quite short name for a package that >> will go into a general purpose software catalog like Debian repository. Would >> you mind choosing something like "github-cli" as source and binary >> package name and mentioning the sortcut "gh" in a package description? >> So anyone could find the program by means of `apt-cache search`. >> Acronyms gh and gn (which stands for Google's Generate Ninja) are >> visually similar, and I'm afraid they are easily confused. >> >> What do you make of this proposal? > > I like that proposal and think it makes a lot of sense. `gh` does seem > too short, and while easy to identify for current gh users, maybe it > will be more difficult to find in apt for new users. Also, as you > mentioned, a namespace clash in the future seems like an uncommon > occurence. It's not on the package name, but there's already a clash on the binary name, which we should be mindful of: anarcat@angela:~(main)$ apt-file search bin/gh | grep 'gh$' gitsome: /usr/bin/gh anarcat@angela:~(main)$ apt show gitsome | sed -n '/Description/,$p' WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Description: Supercharged Git/Shell Autocompleter with GitHub Integration gitsome provides direct integration with GitHub and GitHub Enterprise in a terminal. It includes not only GitHub integrated commands that work with all shells but also provides following functions. . - Git and GitHub Autocompleter With Interactive Help - Fish-Style Auto-Suggestions - General Autocompleter - Python REPL - Command History - Customizable Highlighting Since it's a git (and github, even!) related tool, we might even want to Conflict with it directly... a. -- Qui vit sans folie n'est pas si sage qu'il croit. - François de La Rochefoucauld
Bug#951374: RFP: gh -- the GitHub CLI
On Sun, 8 Aug 2021 10:17:06 -0500 Brian Thompson wrote: > I like that proposal and think it makes a lot of sense. `gh` does seem > too short, and while easy to identify for current gh users, maybe it > will be more difficult to find in apt for new users. Also, as you > mentioned, a namespace clash in the future seems like an uncommon > occurence. Could also add a Provides: gh so it is installable with the short name. I would definitely like to have this in Debian, but can't help with it. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#951374: RFP: gh -- the GitHub CLI
> I personally find that "gh" is quite short name for a package that > will go into a general purpose software catalog like Debian repository. Would > you mind choosing something like "github-cli" as source and binary > package name and mentioning the sortcut "gh" in a package description? > So anyone could find the program by means of `apt-cache search`. > Acronyms gh and gn (which stands for Google's Generate Ninja) are > visually similar, and I'm afraid they are easily confused. > > What do you make of this proposal? I like that proposal and think it makes a lot of sense. `gh` does seem too short, and while easy to identify for current gh users, maybe it will be more difficult to find in apt for new users. Also, as you mentioned, a namespace clash in the future seems like an uncommon occurence. -- Best regards, Brian T signature.asc Description: PGP signature
Bug#951374: RFP: gh -- the GitHub CLI
Hello! I personally find that "gh" is quite short name for a package that will go into a general purpose software catalog like Debian repository. Would you mind choosing something like "github-cli" as source and binary package name and mentioning the sortcut "gh" in a package description? So anyone could find the program by means of `apt-cache search`. Acronyms gh and gn (which stands for Google's Generate Ninja) are visually similar, and I'm afraid they are easily confused. What do you make of this proposal? signature.asc Description: This is a digitally signed message part
Bug#951374: RFP: gh -- the GitHub CLI
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: gh Version : 0.5.5 Upstream Author : GitHub Inc. * URL : https://cli.github.com/ * License : MIT Programming Lang: Go Description : the GitHub CLI `gh` is a command-line interface for the Github source-hosting service; it brings pull requests, issues, and other GitHub functionality to the terminal, next to git and other programming tooling. It is an alternative to `hub`, which was Github's unofficial CLI client. -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl5IBjIRHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7MvYSg//WyxlmrlLhiPeQ4pmDcMgdgnBSob2wRqt xVvbGJFAibGV8FSCTe2kpesyuJqBG4Jy5pprHX6lzvDT4qKh0LWIo7ETzKFnfMcr HBIDtUbBcdypD0VoLnAP7lduybaDb6zDmYxiefVwVtNv01azGhD51on5Hm8qLkNJ yQP43zXjhrb3gokpIOP/YypbOBU6ldaS5eBbI4nWqTWCpY6AOGgxIHkkgPlIbZvn D18/PM/K0SYwuh1fLYDR7rFa4tzhlL4vwbFxGgk4s1hdHOU4xT6o7hTw4Xtp990Q ab8j/Tx1qIcEY3Ahkx0C1K056PN7cYC3f7cUxcz418e8b1tFBQBDfOzNGaA/qVU3 dSHSprpp03EQrDDpkGcH5Tk8CbZB5vF0oHUP6sWAGsOGQ1tNg/uOF2g6GhDFsUrm QIOAhur2yOdlMR3BPrMbqjDh/GATAOETX7Q7bGIoSZ3JUC9Wzf8RXGaaMWYCI8RS 8EQtmA5UFE4Io9VbNk/Wg5MA0p1QJ0rQZ3wf8lw+y8PVJxi0l4wcNF+3W4eWwINO eQxfTPaSFzeOe8yNkHuXs35naNE0/wkHiaYbowG7oKGnzAjb7EU1kWX0WhSSN42S 7qp8OfdV28Kh+fczhztXvXwyYr8vXtmmohTB3pTsyzyZt+6AYbD+Uvi1/0ujA15w IqaQg+nNGDY= =Otf5 -END PGP SIGNATURE-
