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 <[email protected]> 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 > [email protected] > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers -- Best regards, Michael _______________________________________________ Pkg-go-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
