[Build-common-hackers] Ideas for the future of cdbs

[Marc Dequènes (Duck)]

Coin,

Quoting Peter Eisentraut <petere at debian.org>:

> * Require debhelper 7 and rely on its defaults.

Interresting, but i guess this is too early as it would render  
backports more difficult. Perhaps postpone this goal after the Squeeze  
release would be better.

> * Autodetection of rules and classes
>
> For the most part, we can detect the rules and classes needed automatically,
> e.g., if you find a configure file, then use autotools. And everyone uses
> debhelper anyway, so we could make that the default.  So I imagine that most
> users would just have to write

I agree debhelper should be enforced, as most of the CDBS power is  
activated when used, and it seems the step is already partly done (the  
Python class no more check if the debhelper rules were included before  
using dh_python as in the initial code).

The autodetection rule seems a bit dangerous, and one should be able  
to deactivate them if the build system is weird and requires special  
treatment. Probably not making it the default is the best. At least  
this feature could suggest things to the DD. It could be nice to have  
a special rule for general suggestions, for usage, deprecation  
warning, and things that cannot be autodetected in a safe way. it  
could also suggests Build-Depends needed for the modules, thus  
replacing the autogeneration rule.

> * get CFLAGS from dpkg
>
> This is currently under discussion, but dpkg nowadays supplies  
> CFLAGS etc., so
> perhaps we shouldn't override that?

I guess complementing these kind of variables in certain modules is  
necessary, but we should probably review the module's needs first.

> * man page
>
> Many people complain that debhelper has man pages and cdbs doesn't.  So I
> think we could provide extracts from the manual as man pages.

Not sure what we can say besides a generic introduction, as giving  
hints would be overly long.


The other suggestions are fine for me.

Regards.

-- 
Marc Dequènes (Duck)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: PGP Digital Signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20090527/c1eea7b4/attachment.pgp>