<div dir="ltr">Sorry, only saw this email after my other reply. Somehow the threading broke, it seems.<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 7, 2018 at 12:20 PM, Pete Heist <span dir="ltr"><<a href="mailto:pete@eventide.io" target="_blank">pete@eventide.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Feb 7, 2018, at 12:01 PM, Clément Hermann <<a href="mailto:nodens@nodens.org">nodens@nodens.org</a>> wrote:<br>
><br>
> On 07/02/2018 11:39, Pete Heist wrote:<br>
>><br>
>> Ah, ok. IRTT has an API, but it's not published yet. I think a<br>
>> binary-only package may be better at this point, and a separate source<br>
>> package later when that’s ready? If you agree, could you suggest a<br>
>> simple, current binary package hosted on github as a good example?<br>
><br>
> You can have a single upstream package and produce 2 binary packages -<br>
> it's a bit more complicated though. Hence the example of Debian Code Search.<br>
<br>
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?<br></blockquote><div><br></div><div>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).</div><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Usually you would host the packaging on Alioth (soon <a href="http://salsa.debian.org" rel="noreferrer" target="_blank">salsa.debian.org</a>),<br>
> and leave the upstream on github. Debian Code Search is a bit different<br>
> since it's specific to Debian. That doesn't change the usefulness of the<br>
> example for binary/api separation though.<br>
><br>
> Regarding the workflow, the easiest is to tag your releases on github<br>
> (you probably already do it anyway) and merge the upstream remote in the<br>
> upstream branch on alioth/salsa every time you want to release (the tag<br>
> isn't mandatory, it's just easier, and allows for a debian/watch file).<br>
<br>
Got it...<br>
<br>
> You're expected to run unstable (Sid) for packaging work. At least in a<br>
> virtual machine.<br>
><br>
> By the way, it's also a good practice to actually build the package in a<br>
> chroot (using git-buildpackage pbuilder options for instance), to avoid<br>
> build-depends issues.<br>
<br>
That explains a lot. I’ve got my work cut out for me on this part.<br>
<br>
Thank you kindly…<br>
<br>
<br>
______________________________<wbr>_________________<br>
Pkg-go-maintainers mailing list<br>
<a href="mailto:Pkg-go-maintainers@lists.alioth.debian.org">Pkg-go-maintainers@lists.<wbr>alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers" rel="noreferrer" target="_blank">http://lists.alioth.debian.<wbr>org/cgi-bin/mailman/listinfo/<wbr>pkg-go-maintainers</a></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>
</div></div>