[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: debian/include

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!


Reply to: