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

[Michael Stapelberg]

Paul mentions good reasons for just doing #2 for now, so I recommend
that. Eventually we also want to rename the git repositories — can we
use symlinks for that?

On Wed, Sep 9, 2015 at 2:19 AM, Paul Tagliamonte <paultag at debian.org> wrote:
> 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
>
> _______________________________________________
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
Best regards,
Michael