-----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
> <br...@hashvault.io> 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-----

Reply via email to