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

[George Danchev]

On Monday 07 August 2006 14:49, Jonas Smedegaard wrote:
> On Sun, 6 Aug 2006 21:27:44 +0300 George Danchev wrote:
> > By the way, if you find any abusage of the cdbs in sofia-sip package
> > please tell (explain) us so and feel free to fix it ;-)
>
> Looks sane to me.
>
> I've changed one detail: CDBS alreade resolves package version, so no
> need to do that again independently.

Thanks!

> It looks like major parts of the rules file is generic to pkg-voip
> packages. I'd like to separate that into a file initially duplicated in
> each cdbs-enabled pkg-voip package, but when polished adopted by cdbs
> officially.

Well, that is true. Since we are aware of `version resolving feature', the 
next item which could be made common and put into CDBS arsenal is the 
get-orig-source target with hashsum checking capabilities. I filed similar 
wishlist bug (#325161) against dpatch package, but seems like developers are 
not so interested to have it there. I'll left in your capable hands to file a 
similar bts entry for cdbs if needed and handle it as well ;-)

> I would also like to add other similasrly organized cdbs "snippets" (my
> own name for such local-but-adoptable cdbs code fragments):
>
>   * auto-update (auto-update build-deps when DEB_BUILD_OPTIONS=update)

Hm, policy #10.1 says DEB_BUILD_OPTIONS is standardized environment variable 
with values of noopt|nostrip, so better keep is sane and pick a different 
variable to auto-update build-deps ?

>   * copyright-check (check for changes to copyright in source)

What these are changes compared against ?

>   * buildinfo (include details on build env with each binary package)

This is probably nice to have.

> I am also working on a "bts" snippet to both include relevant
> additional info when filing bugreports, but also detect non-Debian
> builds and redirect bugreports to packager (the one finalizing the
> topmost debian/changelog entry) instead of the package maintainer (the
> one tagges as such in debian/control). But it's not ready for general
> consumption yet...

Sounds rather complex ;-)

-- 
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB