[pkg-go] Bug#888985: RFS: irtt/0.9-1 [ITP] (#888985)

[Michael Stapelberg]

Sorry, only saw this email after my other reply. Somehow the threading
broke, it seems.

On Wed, Feb 7, 2018 at 12:20 PM, Pete Heist <pete at eventide.io> wrote:

>
> > On Feb 7, 2018, at 12:01 PM, Clément Hermann <nodens at nodens.org> wrote:
> >
> > On 07/02/2018 11:39, Pete Heist wrote:
> >>
> >> Ah, ok. IRTT has an API, but it's not published yet. I think a
> >> binary-only package may be better at this point, and a separate source
> >> package later when that’s ready? If you agree, could you suggest a
> >> simple, current binary package hosted on github as a good example?
> >
> > You can have a single upstream package and produce 2 binary packages -
> > it's a bit more complicated though. Hence the example of Debian Code
> Search.
>
> Ok, I’m getting there, bear with me. :) In my case, would I not want to
> produce both a binary package and eventually a source package?
>

Be careful not to confuse the Debian concept of source packages (i.e. .dsc
files) and binary packages (i.e. .deb files) with a Debian binary package
containing binary files (e.g. a .deb with files in /usr/bin) and a Debian
binary package containing Go source code (e.g. a .deb with files in
/usr/share/gocode).

You always operate on 1 Debian source package (in your case, named irtt)
generating at least 1 Debian binary package (in your case, also named
irtt). We discussed generating 2 Debian binary packages (irtt and
golang-github-peteheist-irtt-dev).


>
> > Usually you would host the packaging on Alioth (soon salsa.debian.org),
> > and leave the upstream on github. Debian Code Search is a bit different
> > since it's specific to Debian. That doesn't change the usefulness of the
> > example for binary/api separation though.
> >
> > Regarding the workflow, the easiest is to tag your releases on github
> > (you probably already do it anyway) and merge the upstream remote in the
> > upstream branch on alioth/salsa every time you want to release (the tag
> > isn't mandatory, it's just easier, and allows for a debian/watch file).
>
> Got it...
>
> > You're expected to run unstable (Sid) for packaging work. At least in a
> > virtual machine.
> >
> > By the way, it's also a good practice to actually build the package in a
> > chroot (using git-buildpackage pbuilder options for instance), to avoid
> > build-depends issues.
>
> That explains a lot. I’ve got my work cut out for me on this part.
>
> Thank you kindly…
>
>
> _______________________________________________
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers




-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20180207/8e144d38/attachment-0001.html>