Re: Bug#662632: RFS: libaio-ocaml/1.0~rc1
Goswin von Brederlow <goswin-v-b@web.de> writes:
> But then you have to split your workflow again. You have to edit
> upstream files in the master branch and debian files in the debian
> branch. Switching between the branches becomes a pain and working in 2
> workdirs is also a pain. To testbuild you then need to merge from master
> to debian and so on. That is basically as bad as having 2 seperate git
> repositories, one for upstream and one for debian.
This is how I actually want to work; I prefer the separation. But I can
see why you don't want to do things this way (and indeed several of my
coworkers prefer to maintain our local packages as native packages to
avoid this separation). It does mean cherry-picking things back and forth
a bunch while solving some packaging-related problems.
> The upstream branchs buys me that other people stop complaining that my
> package is native.
Ah! Okay, I had somewhat misunderstood the problem. So in that case the
only purpose the upstream branch is serving for you is that it's an export
of the tarball distribution that you can base pristine-tar on, without
forcing pristine-tar to maintain a delta to remove all the debian/* files.
In that case, I would not bother with any of the merging logic and would
maintain the upstream branch as a pure tarball import with git-import-orig
without merging it. That means it would be a disconnected branch without
the "correct" history, but at that point you don't care since it's only
there for pristine-tar to use. Git will still do global object
deduplication, so you'll get the compression advantages.
So, in other words, branch upstream off of master, remove and commit the
removal of the debian/* files, and then from that point forward your
packaging method is to run make dist (which would omit the debian/*
files), git-import-orig the tarball with --no-merge, and then build with
git-buildpackage as you would normally do.
> I glanced at it but wasn't sure how to apply that to my setup where I
> merge from master to upstream. Looking at it again I think
> debian/import-upstream tarball master upstream/x.y
> would be correct. Will try that when I find the time to recreate the
> repository.
Yes, that would work if you want to preserve the history. But since
nothing other than pristine-tar is going to look at the upstream branch,
I'm not sure I'd bother.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: