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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
