Bug#847681: packaging repository and sid diverging? Various fixes needed.
On Wed, Dec 14, 2016 at 08:11:52AM +0100, Daniel Pocock wrote:
>
>
> On 13/12/16 22:46, Andreas Henriksson wrote:
> > On Tue, Dec 13, 2016 at 08:55:34PM +0100, Daniel Pocock wrote:
> >> Hi Ben,
> >>
> >> Thanks for providing this feedback
> >>
> >> I've done the following:
> >> - forked the upstream repository
> >> - created a debian/sid branch
> >> - copied debian/* from jessie into that branch and committed
> >> - copied debian/* from sid into that branch and committed
> > [...]
> >
> > Haven't checked the actual repo, but this sounds horrible to me.
> >
>
> It is not universally bad
I don't want to create additional burdens for you making progress here,
just thought I could suggest alternative approaches that I would personally
use instead.
>
> The benefit is that it makes it easier for integrating with upstream
> work and quickly testing code that upstream hasn't tagged or released, e.g.
>
>
> git checkout master (upstream's master)
> git pull (get latest unreleased stuff)
Well, after following one of my previously suggested methods then you
could just rename the branches (and set up new tracking)
and you can still do it like you're describing.
>
> git checkout -b debian/test-latest-2016-12-14 debian/sid
> git merge master
> vi debian/changelog
> git add debian/changelog && git commit -m 'Test build 2016-12-14'
>
> dpkg-buildpackage -rfakeroot -i.* -b -us -uc
>
>
> When I am working in my own projects where I am upstream I find it very
> convenient to be able to rapidly build and test packages like that
> before tagging my upstream releases. My goal there is to ensure every
> release tarball can work on Debian without patching.
>
> I agree the loss of Debian packaging history is a concern, that is one
> reason I didn't clobber the existing repository and I wrote that we can
> blow this away if there isn't consensus about it.
Yeah, but ever more importantly now is to not get stuck on details I guess.
Regards,
Andreas Henriksson
Reply to: