Hi all, On Wed, May 25, 2016 at 07:29:02AM +1000, Dmitry Smirnov wrote: > On Tuesday, 24 May 2016 1:20:34 PM AEST Vincent Bernat wrote: > > I need this package for use in gobgp which > > uses it through github.com/eapache/channels. > > > > Should I package golang-github-eapache-channels-dev or > > golang-gopkg-eapache-channels.v1-dev? > > > > In the first case, should I provide a symbolic link for > > gopkg.in/eapache/channels.v1 or wait for anything else needing this > > symbolic link? > > I would go with first option because if package ever moves to .v2 you'll only > need to update "Provides" field (and symlink). Providing compatibility > symlink may be useful even if nobody uses it yet.
On the other hand, having golang-gopkg-….vN as separate source and binary packages allows having multiple major versions in Debian when applications depend on different major versions of a package. I recently had a similar case where upstream started tagging release upon our request (golang-gopkg-cheggaaa-pb.v1). I opted for packaging the versioned source package separately, and filed an upstream bug for the downstream package (acmetool) to import gopkg.in/cheggaaa/pb.v1. Once all Build-Depends are converted to the versioned package, I will request removal of the unversioned package (golang-github-cheggaaa-pb). I think it would be wise to have the Go packaging policy recommend one solution, compatibility symlinks or separate source packages. Debian Go team members, what are your thoughts on gopkg.in versioning? Would you support allowing for multiple major versions of a package? Regards, Peter _______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers