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 <p...@eventide.io> wrote: > > > On Feb 7, 2018, at 12:01 PM, Clément Hermann <nod...@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-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers -- Best regards, Michael
