[pkg-go] May I upgrade golang-blackfriday, golang-testify, etc. to latest versions?

[Paul Tagliamonte]

On Tue, Sep 08, 2015 at 06:05:45PM -0600, Anthony Fok wrote:
> > No, but you should rename the existing packages to the proper name.
> > See other recently uploaded packages for examples on how to do that
> > with regards to Breaks/Replaces if you’re unsure about that.
> 
> Thank you for this very important note.  I took some time to examine existing
> packages (basically git cloned 237 Go packages and grep'd for ^Replaces: etc.)
> and noticed slight discrepancies.  Now, regarding the renaming:
> 
>  1. Rename the binary -dev package
>  2. Rename the source package in debian/control (and hence orig.tar.xx too)
>  3. Rename the git repository too, i.e. "ssh git.debian.org",
>      "cd /git/pkg-go/packages", then "mv old-name.git new-name.git"
> 
> Should I just do #1?  (e.g. golang-gocolorize, a new package)
> Or just #1 and #2?  (e.g. golang-golang-x-net-dev)
> Or all three?  (e.g. golang-github-gorilla-mux)

I actually haven't thought about the right thing here -- but some
related thoughts from an archive standpoint:

1: Package enters binNEW, old binary package is marked by NBS, and
   it'll get tracked as archive cruft.

2: Package enters source NEW, marked as a binary hijack, and old source
   package is marked as obsolete source package, and gets tracked as
   archive cruft.

1 and 2: Package enters Source NEW *and* has new binaries, and dak won't
         see the old package as cruft


My thoughts are if we do #1 and #2 at the same time, we must also file
ftp-master removal bugs. If we do #1 and then #2 later, we wind up going
through NEW twice. Or #2 then #1. Doing both is more work on us, and
doing them independently will put more work on the ftpteam (and lag
updates).

That being said, I'm happy to process such things out of NEW.

> And, should I use Breaks/Replaces/Provides with transitional package
> (e.g. golang-golang-x-net-dev) instead of Conflicts/Replaces/Provides
> without transitional package (e.g. golang-github-gorilla-mux)?

I'd avoid using a new package for this, no reason we can't just provide
the package and make it virtual, I guess. Other thoughts on the team?

> Sorry for sounding pedantic, but as I am still pretty new to this
> and will be upgrading/migrating at least a handful of Go packages,
> I would like to know the best way before I dive all in.
> 
> Thanks again!
> 
> Cheers,
> Anthony

Cheers,
   Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20150908/fd734b83/attachment.sig>