> On Feb 7, 2018, at 12:01 PM, Clément Hermann <nodens@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…
_______________________________________________
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ pkg-go-maintainers