[SCM] Debian packaging for jack-audio-connection-kit branch, master.jackd2, updated. debian/1.9.4+svn3842-2-41-g15d16a4
dr at jones.dk
Sat Apr 3 11:14:41 UTC 2010
Hi Reinhard (and others),
On Sat, Apr 03, 2010 at 10:04:11AM +0200, Reinhard Tartler wrote:
>On Fri, Apr 02, 2010 at 20:59:02 (CEST), Jonas Smedegaard wrote:
>>>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?
>> So there is your answer to the questions: No - I commit unapplied
>> patches, not applied ones or quilt noise!
>Hm, but requires additional manual overhead to make sure that you don't
>commit noise. Does this really make packaging easier then?
Sorry for the too short answer (thought I covered the details in my
other mail fired off right before I saw tha above question) - let me try
elaborate a bit more here too:
First it was claimed that git-buildpackage did not work with the new
source format. I believe that to be untrue (and suspect it to be a
rumor held alive by developers that have not actually tried, and perhaps
misunderstood and blown out of proprtions info like that bugreport from
Here you raise the more relevant concern if the new format is beneficial
or brings mors hassle.
I certainly believe it it beneficial (and from that bugreport I get the
impression that Colin feel the same - it is just a _wishist_ bug and he
introduces by higly prising the new format in general):
The distributed source is much easier to handle: a tarball of upstream
source and another tarball of Debian source, rather than the latter
being a diff - which in the case of changes to upstream source becomes
convolutes diffs-inside-a-diff. some may not care, but personally I use
Midnight Commander and frequently inspect source package contents by
"browsing" it using the mc virtual filesystem feature, and here it is
much more usable to browse actual files and diffs than diffs and
Upstream source can be redistributed as-is even when in bzip2 format.
Some may not care. but I happen to prefer using pristine tarballs
whenever possible, and work towards automated ways of validating such
pristine sources when upstream publishes checksums of them - something
which obviously is impossible when repackaging or even generating a
custom tarball from upstream VCS source.
Build process need not be more hassle. Some may not care but I happen
to _like_ switching back and forth between pristine source and source
with patches applied. As I believe I wrote already in an earlier
response, those wanting things as simple and automated as possible have
1) request git-buildpackage to do the build in a separate directory
to not mess with the Git tree
2) tell Git to ignore the .pc directory, and instead of invoking
"debuild clean" instead invoke "debuild clean && quilt pop -a".
If 2) is the preferred way, but still too much hassle, I would be happy
to help design a smapp debuild wrapper script that seemlessly a) removes
.pc dir if only containing dotfiles, and b) unpatches whenever cleaning.
I would not use such script myself, because (as I wrote above) I happen
to use it as a feature, no matter if that was the intend of it :-)
>> I use git-buildpackage, not topgit!
>I don't understand this comment. Topgit managing each "change" as a
Ah, sorry again for being to short:
At some point (last spring, I believe it was), I investigated Topgit as
an alternative to git-buildpage. One of my concerns was that I would
then loose control over the patches: With topgit patches are intended to
be dynamically generated. What is tracked in the VCS is the applied
patches, while the isolated patches are only autogenerated on demand and
cannot properly be maintained in the VCS.
Oh well - this might very well be me not fully understanding the wonders
of the Topgit appreach. I did not mean to expand the discussion here to
include truths and rumors of Topgit - I just instinctively saw a
parallel between the Topgit style and what seems to be your preferred
style: Not track isolated patches in VCS but have them generated
Perhaps you would be interested in gbp-pq, added recently to
More information here (as mentioned in its manpage):
I have not used it myself (I am sceptical to the dynamic generation of
patches) and suspect that it won't solve the noise with dpkg format 3.0,
so just a side note...
>>> 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).
>> You are free to find git-buildpackage silly, and prefer different
>> VCSes altogether.
>This is not what I said,
Whoops, you are right. Sorry! I was too quick on the keyboard there,
writing before reading properly. :-/
You did not bash git-buildpackage in general but only its limited use of
git merge (it is used in git-import-dsc and git-import-orig but not
>and granted, I shouldn't have used the word 'silly' but a less strong
Nah, that's ok. I just think I should've been less jumpy :-)
>I think that Format 3.0 does not work well with git-buildpackage. At
>least, git-buildpackage should integrate more with dpkg so that
>unnecessary "commit noise" is avoided.
>> Am I free to not find it silly? As part of this team?
>I'd very much prefer to work on a consistent set of packages. Having
>some packages maintained in this and some in another way leads
>individuals to look and care only after a subset of our team's
Hmm. Then perhaps I already do not fit in and should go solo again: I
push the use of CDBS which already divides the packaging in two camps,
and also have strong opinion on the use of pristine sources.
What do you think? What do others think?
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: Digital signature
More information about the pkg-multimedia-maintainers