Re: Bug#662632: RFS: libaio-ocaml/1.0~rc1
Russ Allbery <rra@debian.org> writes:
> 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.
Other people might. So say RH wants to see what has changed between
upstream/1.0 and upstream/1.1 then the interconnect of the histories
will allow them to see the seperate commits. Looks better in qgit even
to me, better than as disconnected branch.
I'm fine with experimenting a bit now trying things and will use that on
5 or 6 projects. Making things easier for other people is a good thing.
If I can do it with just some initial overhead and no running costs
(other than some extra commands in the release target or so) then I'm
all for it.
MfG
Goswin
Reply to: