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

Jonas Smedegaard dr at jones.dk
Sun Apr 4 22:34:47 UTC 2010


On Sun, Apr 04, 2010 at 11:06:34PM +0200, Reinhard Tartler wrote:
>On Sun, Apr 04, 2010 at 21:29:21 (CEST), Jonas Smedegaard wrote:
>> Very well.  I will have a look at implementing such hack, then.
>
>How about this:


>diff --git a/debian/rules b/debian/rules
>index bf5eb38..5886dcb 100755
>--- a/debian/rules
>+++ b/debian/rules

When there's a debian/rules.in (as is the case here) then please edit 
that one instead.

When the clean rule is executed while DEB_MAINTAINER_MODE=1 in the 
environment, debian/rules is autoupdated, resolving build-dependencies 
related to included CDBS snippets. I always do that right before 
release, so will then discover and reapply if someone like you here had 
edited debian.rules drectly.


>@@ -3,6 +3,7 @@
> -include /usr/share/cdbs/1/rules/upstream-tarball.mk
> include /usr/share/cdbs/1/rules/utils.mk
> include /usr/share/cdbs/1/rules/debhelper.mk
>+include /usr/share/cdbs/1/rules/patchsys-quilt.mk
> include /usr/share/cdbs/1/class/makefile.mk

...because adding above cause the package to need to build-depend on a 
few additional packages.


> debian/stamp-waf-configure:
>        waf configure --prefix=/usr $(MIXED_FLAGS) --firewire --alsa --classic --dbus
>        touch $@
>-clean::
>+clean:: unpatch
>        rm -f debian/stamp-waf-configure

I recommend to keep unrelated routines separate, even if it causes the 
rules file to be slightly larger, and document unclear intends:


         touch $@
  clean::
         rm -f debian/stamp-waf-configure
+
+# Un-apply patches left behind with source format 3.0 (quilt)
patches
+clean:: unpatch
+

Also, above always un-applies, not only when using git - I am uncertain 
if that will cause problems somewhere.  Not sure waht that might be, 
just worried...


>While we are at it, I'd suggest this change as well for Format 3.0
>packages in general:
>--- /dev/null
>+++ b/debian/source/options
>@@ -0,0 +1,2 @@
>+# use debian/patches/debian-changes as automatic patch
>+single-debian-patch

Why?  I would consider autogenerated patches an error anyway, so do not 
care about its naming.


>> Yeah, true. That one piece is Perl.  And I really should merge that 
>> script into licensecheck itself.  Just haven't taken the time and 
>> social endurance yet to figure out how that package is maintained, 
>> whom to discuss with if ok that I start hack on it to improve it, and 
>> how many different opinions I need to challenge and argue against 
>> regarding Perl coding style, intend of that tool etc. etc. etc.
>
>Ok, I think we agree here. Let's start with a wishlist bug against 
>devscripts for licensecheck2dep5. Do you want to file or shall I?

Go ahead and do it.  Please bug-cc me, as I would like to actually do 
the job of cleaning up licensecheck, if the opportunity is there.  It is 
a little baby of mine, that DEP5 compliant licensecheck output. :-)


>> Just see how much time we've spent arguing about packaging style 
>> here. No, I am not whining, just stating the fact that it takes time 
>> and effort to get involved in yet another development team.
>
>Oh, I don't think this time is wasted, as long as we don't restart it 
>over and over again.

Agreed. I carefully avoided the term "wasted" in my text above ;-)


>However, we mustn't forget to add our conclusions to 
>http://wiki.debian.org/DebianMultimedia/DevelopPackaging

Hmm.  I am unsure what is policy and what is suggestions and what is my 
stubbornness in what we've discussed here - so please you do that, ok?


>> So that one hack is Perl but irrelevant for dkpg-dev.  And other 
>> parts are not Perl so irrelevant for dpkg-dev too.  As I see it.
>
>As for the repackaging tarball functionality, from the first glance I 
>also think it could probably live in devscripts as well; conversion to 
>shell seems really straight forward.

Hm.  Right you are.

Again, I fear the unknown, and who is governing devscripts is unknown to 
me.  You are most welcome to help break the ice, by filing bugreports, 
holding my hand, or tell me the cold facts of how that package is 
maintained... :-)


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/20100405/77b5d12f/attachment.pgp>


More information about the pkg-multimedia-maintainers mailing list