[pkg-go] github.com/XXX/YYY vs gopkg.in/XXX/YYY.v1

[Peter Colberg]

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