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
> I think the main issue is working with applied patches _and_ a
> debian/patches dir...
> 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
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
Reinhard Tartler, KeyID 945348A4
pkg-multimedia-maintainers mailing list