> 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? > 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…
