On Thu, 20 Mar 2008, A. Costa wrote: > Thanks for the clarification. Unfortunately, it therefore follows I'd > be favoring time wasting over-engineering --- provided of course, there > were only two possible ways of dealing with the bug, > (1. the wrong way, or 2. no fix at all). > > But as was suggested to the emphatic JH back in 4/2006, there might be > more than one way to do it: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366555#36
To be clear: this bug #366555 is assigned to dpkg-dev and dpkg-dev doesn't control the timestamp of generated documentation. If you want the generated documentation to have a timestamp that matches the source, you should just write a tool that makes it easy to do so and hope that some maintainers will use it to fix timestamp of the generated documentation (but I doubt it, honestly and the maintainer of debhelper is very much a reference concerning what is a reasonable packaging helper tool). dpkg-dev comes into play only at one place: the timestamp of files patched by the diff.gz (or by debian/patches/* with a newer source package format). Up to now all files from the debian sub-directory are installed by the diff.gz and thus get a timestamp reset by dpkg-source. In the future, when we switch over to the new source format the files in the debian directory will be installed by a debian.tar.gz file and thus we will preserve timestamps. However upstream patched files will continue to have their timestamp reset at unpack time. > (Your replies come in fast, but we've been spending a lot of email > time backtracking. Not sure what you mean, I've read the whole bug log, I do have my opinion and it probably doesn't match your expectation... > > > 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... > > Would a partial fix that only affected '/usr/share/doc/*' be safe from > tricky side-effects? If the files are simply copied over, their timestamp is already preserved. And it's unlikely that we patch upstream documentation. So no, I'm not in favor at all to add any complexity to the timestamp-resetting rule. > > ...But it's not the same when we speak of "configure" > > and "configure.ac" and dpkg-source must not a different behaviour > > "...must not a..."; sorry, is there a missing verb? "have" > > depending on the filename that it patches, it's just too error-prone. > Alas IANADD, and don't know much about 'autoconf', so the meaning of > the above is Greek to me. Maybe you're saying the problem owes more to > the 'autoconf' package than to 'dpkg-source'. No. > Is this one of those political bugs, that belongs in part to several > packages, but is practically insoluble because the maintainers fight? No. It's the normal and expected behaviour of the autoconf tools. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
