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

[Jonas Smedegaard]

On Sun, Apr 04, 2010 at 09:44:48AM +0200, Reinhard Tartler wrote:
>On Sat, Apr 03, 2010 at 13:14:41 (CEST), Jonas Smedegaard wrote:
>
>> First it was claimed that git-buildpackage did not work with the new 
>> source format.  [...]
>> Here you raise the more relevant concern if the new format is 
>> beneficial or brings mors hassle.
>
>git-buildpackage defines a couple of workflows that differ from
>Format 1.0 to Format 3.0 (quilt), so my objection still stands.
>
>> 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):
>
>I'm already sold to the new format for any package that is not 
>maintained by a VCS, no need to convince me of that. Really, my 
>objection is that adding new, contradicting workflows with the same 
>tool that depend on the format is not really something that I want to 
>impose on a team with members of different skill levels.

Good point!



>Is it really too much that simple things like 'build && clean' leave a
>'clean' working directory?!

I believe that I could make a CDBS snippet that cleans up patches and 
.pc dir at clean time when in a git.

Applying the patches at build time should not be necessary, as dpkg 
handles that itself.

Such snippet - like most of CDBS - would *not* depend on CDBS managing 
debhelper too, so should be usable also together with short-form 
debhelper v7.

I believe that would help the point of usability, as then only once 
initially something odd would need doing. Would that be interesting?



>>   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 :-)
>
>And I demand that this wrapper script gets integrated into 
>git-buildpackage, so that simple operations like cleaning and "build 
>and clean" leave the working directory in a clean state.

Makes sense.  Above proposed snippet would only be a temporary measure 
until underlying tools evolve further.


>As long as the workflow for Format 1.0 and Format 3.0 (quilt) patches 
>remain the same, i.e., the same tools work the same on Format 1.0, we 
>don't need two separate versions of the wiki page DevelopPackaging.

Good point!  Thanks.


>Side note, I see that there are some really interesting cdbs make 
>snippets, e.g., the upstream.mk rules etc. I understand that they are 
>still pretty much in flux. Could you imagine to propose a stabilized 
>version (or a subset of them) for dpkg-dev?

It seems to me that dpkg-dev is Perl-based.  CDBS is make-based, so as I 
see it dpkg-dev could adopt ideas only, not actual implementation.

Unless you propose dkpg-dev to be extended to also act as a "cdbs-core" 
which I suspect is unlikely to happen - but maybe that's just me being 
narrowminded...

In other words: Please elaborate.  And I strongly suggest you to do that 
as a wishlist bugreport against dpkg-dev (adding 
build-common-hackers at lists.alioth.debian.org as bug-cc) rather than 
here.


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/20100404/a30ab0c8/attachment-0001.pgp>