Re: Proposal: debian/include

[Morten Kjeldgaard <mok@bioxray.au.dk>]

On 05/09/2008, at 13.56, Raphael Hertzog wrote:

> > by adding to policy an optional file, debian/include, that explicitly
> > lists what files/ directories outside of debian/ should be included  
> > in
> > *.diff.gz. The  format of that file should allow for comments  
> > explaining
> > why those  particular parts are needed in the diff.gz.
>
> This can already be done at run-time with the -i option of
> dpkg-source. In the future, I'll probably give the possibility to
> provide default command-line options in the source package within  
> the file
> debian/source/build-options but I haven't implemented this yet.

As far as I know, the -i option tells dpkg-source to ignore something,  
but what I propose is in fact the opposite... a list of what you want.  
Furthermore, the -i option only works for the person issuing the  
command. If someone else attempts to create a source package, that  
person may not use the -i switch. With a list in debian/include, it  
wouldn't matter how you invoke the tools to build the packge.

> With the new format, if you have local changes, they will be  
> integrated in the
> quilt serie as a new patch and the patch will be automatically named
> by dpkg-source. lintian will probably (one day) warn about such  
> patches
> because when you modify the upstream sources, you must have a good  
> reason
> to do it and thus you should be able to give a proper name to the  
> patch
> and describe it instead of just letting dpkg-source record the change.

I appreciate that this can be a useful feature, but it does not really  
change the situation where you end up with a bunch of undesired  
patches because of things you have done to the source tree. It only  
changes _where_ those patches appear, but you still need to fix the  
source tree so they are not built.

The advantage of the debian/include file is that the packager is  
completely in control of what goes into diff.gz (or quilt patches, for  
that matter), namely nothing if the file is empty. And this  
information would remain with the source package.

> Feel free to give a try to the new format and see if there are
> other things that can be improved to resolve your concerns.

I am certainly interested in learning more about the new format!

Cheers,
Morten