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

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 
Colin).

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 
diffs-of-diffs.

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 
several options:

   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 
>branch (AFAIUI).

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 
on-the-fly.

Perhaps you would be interested in gbp-pq, added recently to 
git-buildpackage.

More information here (as mentioned in its manpage): 
https://honk.sigxcpu.org/piki/development/debian_packages_in_git/

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 
after that).

>and granted, I shouldn't have used the word 'silly' but a less strong 
>word.

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 
>packages.

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?

Kind regards,

  - Jonas

-- 
* 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
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100403/0fe350e8/attachment-0001.pgp>