Hi Mattia, On Fri, May 12, 2017 at 08:21:11PM +0200, Mattia Rizzolo wrote: > Package: git-buildpackage > Version: 0.8.12.2 > Severity: wishlist > > So I had a chance to try out the multiple upstream tarball support and I > have to admit I am very happy to finally have some support to the > everyday's tool that gbp is :) Thank you for it! > > I have a wishlist though. > Here I added a new "contrib" module injected with a separate upstream > tarball: > https://anonscm.debian.org/git/debian-science/packages/opencv.git/commit/?id=2e8087f9d5730b8decf024d51ba8d15df0a2860a > > Incidentally, while bumping the upstream version (+dfsg → +dfsg1) I also > repacked the main tarball by removing another file, and apparently > several other things changed too. I think I'd find a lot more clear if > the import was done with separate commit, i.e.: > 1. import main tarball > 2. commit "New upstream version 3.1.0+dfsg1" > 3. import secondary tarball > 4. commit "Import upstream tarball 'contrib' version 3.1.0+dfsg1" > 5. iterate from point 3 if more multiple tarballs > > Or something like that. The upstream/* tag should be on the last > import, and then merged into the debian branch. > > Thoughts?
I thought about this when adding multiple tarball support but decided to go for one commit since splitting this up would not help when changing a single tarball (I assume that's what you're looking for) if we use the above mode. It would only help if the above would be modified to: 1. import main tarball and keep all component tarballs as is … 3. import secondary tarball and keep main tarball and all other component tarballs as is … and if we do that it would be much harder for people having lots of additional tarballs to be sure everything got updated so I opted for the current mode. That said I'm not totally oposed to change this but want to understand the reasons better first. Cheers, -- Guido
