On Tue, 18 Mar 2008, A. Costa wrote: > > The long bug log clearly says that there's no point to try to conserve > > timestamps for generated documentation. And I agree with that. > > Time permitting, would you kindly tell me where it says that? I reread > the whole BTS log for #366555 yesterday, but might have missed or > even misread something.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366555#31 I totally agree with Joey's comment. Adding supplementary infrastructure to conserve timestamp on generated files is just a waste of time. and over-engineering for very little value. > > - but files patched by one or more of the patches in debian/patches/ > > will always have a timestamp that advances artificially at each > > unpack. This is required because if we don't ajust their timestamp to > > a single value, the timestamp difference means that we can have > > tricky side-effects like regeneration of some files due to timestamp > > skew (e.g. when you patch *.ac or *.in files from autoconf/automake) > > IANADD, could you or somebody give a less abstract example? Suppose > '/usr/share/doc/freeguide/FAQ.html' was dated a week earlier than > '/usr/share/doc/freeguide/TODO'; what bad thing would happen? Nothing of course. But it's not the same when we speak of "configure" and "configure.ac" and dpkg-source must not a different behaviour depending on the filename that it patches, it's just too error-prone. If you have a Makefile rule: configure: configure.ac #regenerate configure Then the fact that configure.ac is newer than configure will imply execution of the rule when it's not wanted. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
