On Sun, Apr 04, 2010 at 03:56:24PM +0200, Adrian Knoth wrote:
On Sun, Apr 04, 2010 at 02:26:48PM +0200, Jonas Smedegaard wrote:

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?

I don't find this annoying, I could perfectly live with it.


My personal opinion is quite the opposite, I hate tarballs, I believe
they're obsolete in times of version control systems, they complicate
work due to always being outdated and so on and so on.

But since this is a developer's point of view and not a packager's
perspective, I'm fine with pristine tarballs and, if need be, one
additional vcs diff. (where's the difference to directly basing
everything on a vcs checkout and strip this one?)

That's exactly the point: development vs. (re)distribution!

Tarballs are that boring old tedious format for exchange: the lowest common denominator.

Debian packaging is based on tarballs, so from a global Debian POV any derivation off of those tarballs complicates matters - even of from other POVs it is more convenient.

The only time I ever do tarballs of my own work is when it is needed for redistribution. So I guess I completely agree with you from a development POV :-D

Did that answer your question above, or should I elaborate more?

Regarding b) that other ongoing discussion touched the general concern of complicating maintainance in this team by having multiple packaging styles.

What I've seen in the team so far: make it work. Besides this, there are no to few rules.

We don't have a "please beginners" policy.


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?

I guess we won't vote against CDBS, so, yes please, go ahead. ;)


I would also be surprised if you did so - I am just trying hard not to be too biased in summarizing, so deliberately try to skew _away_ from my own preferred standpoint.

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" :-)

You are the DD, I'm only the DM. I'm more involved upstream, you downstream. In other words, you know what's right for Debian, I know what's right for jackd (again: developer vs. packager).

I am _a_ DD.  There are many many ways. :-)

But ok - I get the message: I will repackage my way.

...and regarding waf, I think I came up with a sane design: Store a checksum of the waf file, and if the actual waf does not match then refuse to invoke it and instead warn that it should be checked for validity and for licensing, and the checksum updated when ok.

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

Is there a list of CDBS targets? This looks interesting.

There is the source: CDBS is just a bunch of (carefully composed) make snippets below /usr/share/cdbs - go check them out yourself! :-)

You are not the first to ask for a definitive list of targets and variables. It is in the TODO (or actually not, but in my mind and possibly in some bugreport too). CDBS is seriously underdocumented.

To me, the package looks good. If you like, base it on 1.9.5 and upload it. I think I'll be able to cope with CDBS, it surely has some good features, especially the copyright checks. In case of problems, I'd simply ask you. ;)

Thanks for mentioning. I have spend VERY long time refining that particular routine! ...and it is far from complete.

PS: You might want to join #debian-multimedia on irc.oftc.net. It's sometimes easier to answer questions in realtime.

This email has taken me, hmmm, about 1/2 hour to write. You would completely have lost track of the context if I'd done it in same pace on IRC.

Or rephrased: IRC is realtime, which is beneficial for getting a response, but the responses are seldom deeply reflected.

I do not mean to say that I only want to do deep reflection, just that technical discussion IMO are better done through email, while IRC and Jabber is better for "hanging out".

...and I try to avoid "hanging out" too much, as it is soooo fun that I loose track of time and never get any productive work done when engaging in it. Which I know is a silly standpoint, because what's to life if I only work work work and never have fun. I know, I know...

...I might stop by that IRC room at some point. Just not now :-)

 - Jonas

* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature

pkg-multimedia-maintainers mailing list

Reply via email to