On Tue, 18 Mar 2008 08:11:35 +0100 Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> 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. 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 (Your replies come in fast, but we've been spending a lot of email time backtracking. Perhaps lately you're too busy, rushing about with the DPL thing, for my discursive style of email? And good luck with that election, here's hoping your ideas on "transparency and communication" will bear fruit!) Re: "very little value", that's harsh. No objection if you meant "relatively little value", which allows for different priorities and preferences. > > > - 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... Would a partial fix that only affected '/usr/share/doc/*' be safe from tricky side-effects? > ...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? > 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. 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'. Is this one of those political bugs, that belongs in part to several packages, but is practically insoluble because the maintainers fight? Summing up: back to 4/2006. More than one way. RH '08. Level of complexity controversial. Some methods deprecated. Where is the bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
