jackd2 ready to roll

Sun Apr 4 12:26:48 UTC 2010

On Sun, Apr 04, 2010 at 12:25:02PM +0200, Adrian Knoth wrote:
>On Fri, Apr 02, 2010 at 01:30:21AM +0200, Jonas Smedegaard wrote:

>> Is it ok with you that I repackage from the current vcs-tarball to 
>> pristine-(or-repackaged)-tarball + vcs-patch?
>
>I'm not sure if I'm qualified to give an answer that respects all 
>implications of this question. I also don't understand half of the 
>quilt-gbp discussion, so I have to rely on the assumption that you know 
>what you're doing. ;)

Thanks for pointing out some things that you cannot follow of the 
routines that I do:  That helps me know what need clarified :-D

So let me try elaborate on the implications of my question, to help you 
make a qualified decision if you agree on it or not:

The question is separate from that other discussion about Git packaging 
style and its clashing with the use of dpkg source format "3.0 (quilt)".

The issue here, as I see it, has 2 implications:

  a) Basing our packaging on upstream tarballs or only on upstream VCS
  b) Having me do any of the packaging work

Regarding a) this has been discussed in detail recently on the list. 
Here I will summarise as a proposed new policy for this team:

  1. Use upstream tarball when possible.
  2. When impossible due to no upstream tarball at all, discuss first 
     in the team if this should be packaged at all, as that often 
     indicates a frequently moving target, which either might be unfit 
     for redistribution or perhaps needs special care (e.g. overriding 
     shared/static library handling).
  3. When "impossible" due to major changes since last tarball release
     and current VCS, discuss first in the team, as there is a high
     risk of accidentally releasing too experimental code.

Since problems have been discovered in the currently prepared packaging 
by you, requiring a repackaging, it makes sense to bring up the question 
now for this specific package.

Since TTBOMK there is no current team policy conflicting with above 
proposed one, I see no need to discuss that proposal before applying it 
to this specific package.

So regarding a) I believe it boils down to a guestion of whether or not 
you will find it annoying that I isolate the changes between latest 
upstream tarball and the VCS snapshot that you prepared, and include 
that difference as a patch?

Regarding b) that other ongoing discussion touched the general concern 
of complicating maintainance in this team by having multiple packaging 
styles.  I have a strong opinion about CDBS vs. short-form debhelper 7 
and insist on aggressively use CDBS while _avoiding_ short-form 
debhelper 7.  This has already affected simplicity of packaging in this 
team, and it is a relevant question if the team is better off without 
me.

There is a common misunderstanding about CDBS that it is targeted 
beginners, and helps hide complicated parts of packaging.  That is IMO 
wrong, and even dangerous: CDBS is better seen as a tool for advanced 
packaging.  When I claim that CDBS is easy to use (and I do claim that) 
then I do *not* mean that it is possible to avoid understanding what is 
going on during the packaging process, only that you need not explicitly 
declare all the tedious parts of it but can use a CDBS templating 
snippet for most if not all of it.  YOU ARE STILL RESPONSIBLE for what 
you let CDBS do for you.

So if a goal of the Multimedia team is to keep a low entry bar for new 
developers, and to keep all packages equally easy for new developers to 
engage in maintaining, then perhaps you should avoid CDBS and only use 
debhelper.

I say "perhaps" because I really do not know the parts of debhelper 
trying do reinvent the wheel of make - those enabled in short-form mode.  
And I have no interest in learning, because I fundamentally find it a 
wrong approach.  Maybe some day when everyone else in Debian have 
abandoned CDBS and Debian Policy changed to not have debian/rules be a 
make file but a debhlper config file, I might change my mind, but 
currently I cannot imagine that happen.

So I guess b) boils down to a question if you will allow me to infest 
the JACK packaging with even more CDBS now, potentially making it 
cumbersome to change later when maybe the team decides to avoid CDBS?

>In other words: if you say that tarball+vcs-patch is the right way to 
>address all the copyright issues in the jackd2 package, then go ahead.

Define "right way".  It certainly is "my way" :-)

>jackd2-1.9.6 will probably contain most of the things we need, that is, 
>ffado port naming and manpages. ;)

...meaning either a) I am silly to waste my time on this since it is 
soon irrelevant (but hey - why bother, it is my time, pride and 
stubbornness, not yours), or b) you can simply delay answering my 
question until upstream at some point release that new version as a 
tarball.

>Could give a little hint how to repackage/strip new upstream versions, 
>so more than one person in the team knows how to do it? ;)

Most certainly:

   dch -bv 1.9.5-1
   debian/rules get-orig-source

Voila - that should give you a tarball repackaged from pristine source, 
below ../tarballs/

That was the ultra-short version.  Please clone calf (debcheckout calf) 
and read debian/README.source for the longer version.  And please do 
propose improvements to that text (it is reused across 50-80 packages).

Yes, I no that it is inelegant to need to manually edit the version 
number, but that's the state of affairs currently.  Ideas for 
improvements to the get-orig-source routine are most welcome :-)

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/41e9e014/attachment.pgp>