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

[Vincent Bernat]

 ❦ 25 mai 2016 16:32 -0400, Peter Colberg  :

>> > 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.

Since this was not consensual, I did go with gopkg.in + a symlink. The
main reasons is that packages from the same upstream also are in this
namespace.

I already did the upload, but should I had added "Provides:
golang-github-eapache-channels-dev"?
-- 
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [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

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Dmitry Smirnov]

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.

-- 
Best wishes,
 Dmitry Smirnov.

---

Good luck happens when preparedness meets opportunity.


signature.asc
Description: This is a digitally signed message part.
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Vincent Bernat]

Hey!

I have filed an ITP for github.com/eapache/channels. Upstream tags
releases and they are also available through
gopkg.in/eapache/channels.v1. 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?

Thanks.
-- 
The devil can cite Scripture for his purpose.
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers