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

[George Danchev]

On Monday 07 August 2006 18:03, Jonas Smedegaard wrote:
> 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... :-)

Well, feel free to demonstrate that with sofia-sip.

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

OK, but just to make it clear for myself, you will not going to revive 
#311724, right ?

> > >   * 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/002
>791.html

That is fine.

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