[pkg-go] Simple binary + library package example

[Tong Sun]

>
> >* I'm not asking for extensive and comprehensive explanations. *

>* I'm only asking for some simple instruction on the major steps/tools*

>* involved. *



> dh-make-golang gets you started by creating a gbp-style repo, containing
> the basic Debian packaging files. For very simple packages it's already
> enough and works out of the box,
> although you still need to edit a few things here and there. For more
> complicated packages, consider the packaging files generated as
> a starting point. Then you will have to use your debian packaging
> skills, and look at other similar packages, to work your way to a
> working package. Notice that you must be familiar with git buildpackage
> (gbp), because
> that's where dh-make-golang takes you, with 3 branches: 'master',
> 'upstream' and 'pristine-tar'. If you have never worked with gbp before
> you will have a hard time. As for `dh-golang`, it is used to build golang
> packages indeed. If you
> look at the `debian/rules` file generated by dh-make-golang, you will
> see something like `dh $@ --buildsystem=golang --with=golang`. This is
> what triggers the use of dh-golang.



Thanks for the detailed explanation Arnaud. This is exactly kind of things
I was looking for.

I know we new maintainers need to connect the dots ourselves, but the
problem is I don't even know what dots to connect, having already read all
the go packaging materials I can find, despite the fact that I know how
to maintain normal Debian packages, and have already maintained several.
E.g., this is the first time I realized that gbp is involved (I admit that
I only paid attention to the comments/instructions, not lines after lines
of the code. Well, to be accurate, I noticed the `gbp` three character when
I first read https://pkg-go.alioth.debian.org/packaging.html, but I had no
clue what it is and had made a todo item to lookup for what `gbp` stands
for).

Maybe it is a more a personal taste, but I'd like to read before leap.

*Just as a comparison*, some people would swirl into action on only see
this

*quickstart
<https://docs.microsoft.com/en-us/azure/cloud-shell/quickstart> on Cloud
Shell <https://docs.microsoft.com/en-us/azure/cloud-shell/quickstart>*:

*Cloud Shell Quickstart
<https://docs.microsoft.com/en-us/azure/cloud-shell/quickstart>https://docs.microsoft.com/en-us/azure/cloud-shell/quickstart
<https://docs.microsoft.com/en-us/azure/cloud-shell/quickstart>*
But I'd like to read more before following suit to create my own Azure VM,
because there are so much info missing for the

*quickstart <https://docs.microsoft.com/en-us/azure/cloud-shell/quickstart>*
.

I'd like to use the same approach for go packaging as well, if possible,
but I have found so many missing steps when it comes to go packaging.
E.g. (apart from what `gbp` stands for) what steps needs in turning from
https://github.com/containerd/continuity
to https://salsa.debian.org/go-team/packages/continuity?

maybe it is really trivial, but then it doesn't need much explanation
either. Otherwise, it becomes a missing step for new maintainers.

Moreover, speaking of gbp, is it still the correct tool to use when I'm
also the upstream author? E.g., will the 3 branches: 'master',
'upstream' and 'pristine-tar', still necessary? Or we'd better keep them
separated just like what
https://salsa.debian.org/go-team/packages/continuity is doing? But wouldn't
it double the amount of work?

Overall, I know it is not hard for all your experienced go maintainers, but
some might have forgot how hard it was for the new comers to pick up. Well,
I must stop complaining, and give up my "look before leap" motto, and start
cracking...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-go-maintainers/attachments/20180602/7a7f8215/attachment.html>