CDBS wishlists (Re: asterisk dapper.2114_to_dapper.2234 diff)

[Jonas Smedegaard]

On Mon, 7 Aug 2006 18:35:17 +0300 George Danchev wrote:

> > Instead of thinking in terms of "file bugs about each feature", I
> > believe the better approach is to write and use custom snippets, and
> > pay attention to its reusability (and coding style: match upstream
> > cdbs as much as possible) when writing them.
> >
> > I'll demonstrate by example - first srtp (bug#375047), then
> > sofia-sip, and then a branch of asterisk. If noone objects, that
> > is... :-)
> 
> Well, feel free to demonstrate that with sofia-sip.

Thanks. Quicker to hack on an existing (and nice, tight, well-coded
cdbs-based) package than a new one. Plus it makes it easier to see what
was changed :-)


But not today - I have other more urgent stuff pending...



> > Similar to setting up a build environment which always enables
> > debugging, one can be setup to always auto-update build-dependencies
> > (which is disabled by default as it violates Debian Policy - I can't
> > remember which section, and fail to locate it currently).
> 
> OK, but just to make it clear for myself, you will not going to
> revive 
> #311724, right ?

In that bugreport Joerg mixes problem with possible solution.

Problem is "update automatically".

The proposed solution is "never update through normal make targets".

My solution is "update through normal build targets, but only ever if
explicitly enabled".

So I very strongly believe that I am in compliance with Debian Policy,
but also expect others to (at first) disagree.

As an example, I imagine lintian and linda possibly showing red flags
(they don't currently, because they only look for the switch in the
main rules file, not the included snippet), but I have not had any
complaints from Joerg or others since switching to my current "disable
by default" approach.


> > > >   * copyright-check (check for changes to copyright in source)
> 
> What these are changes compared against ?

Ah, sorry - I forgot to comment on that one :-)

 1) Grep'ing the source for copyright patterns.

 2) Compare against manually stored list of checked lines.

So in essence, it is compared against (earlier runs of) itself.

It is thus no magic cure for copyright or licensing misunderstandings,
but a tool to avoid changes to copyright info of a new release slipping
through without getting properly added to debian/copyright (or, if
needed, stripped from the source!).


 - Jonas

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

 - Enden er nær: http://www.shibumi.org/eoti.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20060807/1b70cc6f/attachment.pgp