[SCM] Debian packaging for jack-audio-connection-kit branch, master.jackd2, updated. debian/1.9.4+svn3842-2-41-g15d16a4

[Reinhard Tartler]

On Fri, Apr 02, 2010 at 16:36:12 (CEST), Felipe Sateler wrote:

>>> Until we have a clear idea on how format 3.0 (quilt) should be used with
>>> git-buildpackage, I'd suggest to revert this change.
>>
>> Current consensus where? In the Multimedia team?
>
> Yeap. See the log of the first IRC meeting.
>
>>
>> I fail to understand how a wishlist issue like bug#572204 should stop us
>> from using the new source format.
>>
>> If anyone is confused about how the new format works and can integrate most
>> elegantly with our packaging style (which is similar but not entirely the
>> same as the preferred one of Colin Watson) then let's discuss it - I believe
>> I have found a useful set of routines, which could be put into
>> README.source.
>
> I think the main issue is working with applied patches _and_ a
> debian/patches dir... 

exactly.

> If one does not use --export-dir git-buildpackage fails miserably.

I've never used that option, but after reading git-buildpackage(1), I'm
not sure if this helps.

Jonas, perhaps you answer these questions:

 - do you commit the quilt control directory .pc/?

 - do you commit the tree with patches applied?

 - if not, is everyone expected to run 'quilt pop -a' before committing
  changes to the tree?

Sorry, I still think this mode of operation is pretty silly. I'd much
prefer if the patches were maintained by git-buildpackage as proper git
commits instead of text files. Upon source package generation, these
commits need to be exported as quilt patches of course. This way,
updating to a new upstream version would use git's conflict resolution
mechanisms instead of quilt (which can only merge 2-way, git can do a
3-way merge).

I guess other VCS systems like hg or bzr at least try something in that
directions (although I have to admit that I didn't follow the latest
developments there).

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4