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

[Jonas Smedegaard]

On Mon, 7 Aug 2006 15:13:46 +0300 George Danchev wrote:

> > 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 ;-)

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


I also favor declaring files to install using cdbs variables rather
than *.install files, as files can then be added/subtracted
conditionally (probably relevant for the multiple variants of asterisk).


> >   * 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 ?

It says "This variable can contain several flags to change how a
package is compiled and built." and then continues to describe in
detail two such possible flags that is well-defined.

I fail to read that as a policy against extending the flags. On the
contrary, I see it as well-defined way to pass custom flags to a
build-process, recommended by Policy to be supported also by
build-daemons: They can be expected to preserve DEB_BUILD_OPTIONS but
strip other variables when sanitizing a build environment.

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).


> >   * 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 believe so, yes. Happy that you notice the potential. See the
comment in paranthesis here:
http://lists.alioth.debian.org/pipermail/build-common-hackers/2006-June/002791.html

:-)


> > 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 ;-)

I am just drawing a picture of the possible stuff that snippet can be
extended to do. A first release of it will probably handle only the
divert-to-packager part (instead of the hardcoded address I have in
my current draft snippet, used for some of http://debian.jones.dk/ ).


 - 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/05df1b3c/attachment.pgp