[SCM] calf audio plugins packaging branch, master, updated. upstream/0.0.18.5-52-g6387a5c

[Reinhard Tartler]

On Do, Feb 11, 2010 at 14:05:06 (CET), Jonas Smedegaard wrote:

> On Thu, Feb 11, 2010 at 01:43:40PM +0100, Reinhard Tartler wrote:
>>On Do, Feb 11, 2010 at 13:18:40 (CET), js at users.alioth.debian.org wrote:
>
>>>     Declare build-dependencies indirectly in rules file (not directly
>>> in dontrol file) to ease commenting and manipulation.
>
>> whoho, cdbs now requires to note the build dependencies in
>> debian/rules?
>
> Nope, it *allows* but does not *require*.  Feel free to continue adding
> dependencies in debian/control as usual.  Just allow me to move them to
> debian/rules later on.
>
>>Why does that remind me of yadayada?
>
> I was around when yadayada was still around, but never succeeded
> understanding that beast.  If I recall correctly, it was impossible to
> do an NMU of a yadayada-based package by changing debian/control, as
> yadayada would regenerate that file.  This is not the case here.
>
> But please do educate me: what is flawed in my approach?

I cannot comment on the correctness of 'your' approach, for cdbs package
this is probably just correct. It is just that maintaining cdbs packages
in general, and this package with your experimental cdbs developments in
particular, maintaining it becomes increasingly different to the other
packages we have in pkg-multimedia, which most of them use
debhelper. The same applies btw with the switch from 'classical' dh6 ->
dh7 'new style' packages.

So maybe I'm just suffering the NIH syndrome.

>>Not that I'm strongly against cdbs, but this is very involved black
>>magic going on here. Please don't expect other team members to peer
>>review these kind of changes.
>
> I did not expect anyone to do anything they don't like.  But I certainly
> do not want to alienate myself completely either :-)
>
> Which part do you consider "black magic"?  Every change I did or only
> this move of dependencies?  Did you see my later commit making use of
> that change?

With "black magic" I'm referring to the use of undocumented variables
that for themselves are more or less self speaking, but are not remotely
guessable without being intimely familiar with cdbs internals.

And probably that it feels totally differently to debhelper packages.

>> perhaps it makes sense to (temporarily) disable the postcommit hook
>> for the calf package, at least until this cdbs black magic stuff has
>> settled?
>
> Ah, I didn't think of that possibility.  I thought that a commit list
> was for *all* commits and enyone wanting to use if for review would
> simply skip irrelevant ones (as that is somewhat subjective).

yes, that's what I do for now.

> Which kinds of changes is it generally preferred that I not annoy the
> team with noise about?

Good question, I generally cleanup (with 'git rebase -i') my changes
before pushing to minimize the amount of mails. Your latest patches
however did look fairly clean already, so that probably wouldn't have
helped that much. I guess that's just "normal" development work on the
package.

> And how do I most conveniently switch on and off that hook?  I know that
> I can log into the server and change the execute bit of the hook itself
> but that also affects others potentially commiting at that time.

I'm not aware of other ways to achieve this. But since Adrian actually
wants to read those commit logs, I'd say don't change anything here and
just continue your work on the package!

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4