Hi, I've also gotten a bunch of bug reports from this MBF. Some were easy to fix, but there is one subtype of this issue where I think the commonly given advice and policy currently contradict.
This concerns files that: - are shipped in the upstream tarball - are regenerated (with slightly different contents) during the build These are essentially build products prebuilt by upstream. A commonly recommended approach to fix this, and also the only approach listed on the page linked by the bug report [1], is to add such files to the extend-diff-ignore dpkg-source option. [1]: https://wiki.debian.org/qa.debian.org/FTBFS/DoubleBuild AFAICS this causes dpkg-source to simply ignore changes in this file, preventing dpkg-source from raising an error due to such modifications. However, the policy 4.9 says: clean (required) This must undo any effects that the build and binary targets may have had, except that it should leave alone any output files created in the parent directory by a run of a binary target. So this does not say "dpkg-source must still work after the build + clean", it says that *any* effects of the build must be undone, which is stronger. So AFAICS the extend-diff-ignore fix does not comply with the policy in its current form. Also, it means that two subsequent builds will not start from an identical source tree, which *could* hurt reproducibility (though in practice these files will be regenerated, so the build *should* be identical anyway). Another fix mentioned in this thread (and I also found it in the debmake docs [2]), is to remove such files in the clean target. The net effect is that if you do a build and then build a source package, these files will be removed before calling dpkg-source and since dpkg-source does not error out about deleted files (as it does for modified files), dpkg-source is happy and the source package is created. However, dpkg-source does print a warning, making me feel this is a hack rather than a proper solution. However, this approach *technically* complies with the policy for the clean target, it feels a bit like hack. The clean target restore everything changed by the build target, but does not need to restore the changes it made itself. On the other hand, assuming that clean is called before every build, that does ensure that every build has the same starting position, which I guess is what really counts. [2]: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#rules-clean In terms of short and long term actions to address this, should we (in no particular order): - Add the remove-files-in-clean approach to the wikipage linked in the bug reports [1]? - Modify the policy to allow clean to not revert changes that are excluded by (extend-)diff-ignore? - Modify dpkg-source to not complain with a warning about deleted files (maybe still an informational message to prevent surprise)? - Modify dpkg-source to to complain about any modified files at all (blanket fix for this issue)? What is the point of this check anyway? Note that other parts of the original thread have discussed modifying the policy so building source after build+clean (or even build after build+clean) would no longer required, but since that seems to be a big and controversial change, I'm focusing this post on the current situation of policy and recommended approaches instead. Gr. Matthijs
signature.asc
Description: PGP signature
