[pkg-go] Simple binary + library package example

[Clément Hermann]

Hi,


On 02/06/2018 17:56, Tong Sun wrote:

> 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). 


As a side note, it's still not mentioned on the start pages (the current
one, https://go-team.pages.debian.net), but the team agreed a while back
to change a few things:
https://go-team.pages.debian.net/workflow-changes.html


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

We (go team) are definitely lacking a bit in this area. It's not that we
don't have documentation and good practice, but some are still in the
making and they are hard to find. Asking the Mailing List or IRC is
always a good idea. As a beginner, that's what I do as well ;)

> 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. 

Actually, appart from the specificity in "workflow changes" I mentioned
above, dh-make-golang documentation and git-buildpackage (gbp)
documentation have step by step instructions. It's true it could be
better - and I'm sure we welcome help in this area !

The thing is, GBP is kinda ubiquitous in Debian nowadays, at least in
teams. Once you get some basic concepts, the workflow changes doc above
makes sense.

just in case you don't have it already, GBP documentation:
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html

(also locally: /usr/share/doc/git-buildpackage/manual-html/)

> 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? 
> 
Not exactly sure what you mean, so I'll just assume, please correct me
if I did not get you.

I think upstream development and debian packaging should be separated. I
am upstream for openpgp-applet (hosted on salsa), and I package it in
the perl team separatly, following the procedures of the team. And
sometimes someone from the team fixes stuff in the packaging, which is
great, and the reason I want the package team maintained. It is a
different work after all - even if as an upstream, I try to be nice to
myself as a Debian packager ;)

The idea is that whatever my worflow is as an upstream, it's better if
all packages of the same sort are done the same way, that way anyone can
work on it. Especially in teams where there are a lot of package like
ours. You never know when you'll have to do work on many packages at
once (a recent example is migrating from alioth, but it could also be a
change in policy for instance). So we need to have all the packages
packaged the same way, if we want them team-maintained.

Regarding the branches, please refer to the workflow change document I
linked above, there are a few things that are different from the
"standard" gbp workflow. For instance, we don't use pristine-tar anymore.


> 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... 
> 

Hope this helps a bit. Feel free to share notes: we could use this as a
way to improve our documentation, at least.


Cheers, and thanks for your work :)

-- 
nodens