>>>>> On Tue, 30 Oct 2007 22:56:23 +0000, Barbie <[EMAIL PROTECTED]> said:
> On Tue, Oct 30, 2007 at 09:02:09PM +0100, Andreas J. Koenig wrote: >> Eeeeek. This only ever occured to me when I tested something coming >> from Australia with improper timestamps. But nowadays I usually test >> within seconds after the upload so of course it happens more often. >> (But I'm pretty sure I have set up NTP correctly) > I don't think NTP is so much the problem, more that the time on the > server that created the tarball and your server are different. As users > don't normally download as quickly as you do this isn't usually a > problem. Agreed >> > I would prefer CPAN.pm be able to acknowlegde this >> > and rerun the process of 'perl Makefile.PL/make' as appropriate. >> >> Depends what you mean by "as appropriate". > I was thinking 'touch Makefile.PL' followed by the 'perl > Makefile.PL/make' process. CPAN.pm could detect whether the unwrapped > Makefile.PL/Build.PL has a timestamp in the future to the server > clocktime and attempt to correct this. This would work in some situations but not in all. Other files in the future would also disturb make. Heavily. So we would at least have to bring all files from the future to NOW(). But two files with the same timestamp confuse make too. So one would probably try to shift all timestamps by the same amount of seconds. You see, this sounds more like a MakeMaker job. >> Wait until the time is >> reached that this user thought being NOW()? > I don't think that would be suitable as it could be hours or even days > if inappropriately timestamped. Exactly. >> So to satisfy 'make' we would have to manipulate >> timestamps and this would naturally be a job for MakeMaker, not for >> CPAN.pm. > No, the problem is before the the 'make' stage. I suspect this is a > problem for CPANPLUS too. Yes. >> Hrm, as I said, I don't know a good solution at the moment. > Would the check and touch scenario be possible? I believe, if we shift all timestamps by the same amount of seconds it would work reliably. But there will be new edge cases. Or for small amounts of time just sleep until we reach the time of the Makefile.PL. I like this idea. Imagine: <red>Hey, this Makefile.PL has a timestamp in the future. Hmmm. Only 24 seconds. I'll wait that long to make 'make' happy</red> <blue>\rwaiting 24 [...] \rwaiting 1 [...continue...] --or-- <red>Hey, this Makefile.PL has a timestamp in the future. Hmmm. More than 120 seconds. Please fix the timestamps or report this as a bug to the author or build later or build it later</red> What do you think? >> Yes, I untar these files again and again for every perl that runs the >> test. Looks like a few seconds passed between the tests. The Date >> header on the website is nonsense, it reflects the time when the email >> arrived. I know the sequence in which they were produced 723228 >> (5.10.0; -24 secs), 723217 (5.9.5; -11 secs), 723219 (5.8.8; >0 secs). >> You understand now how it fits together? > Yes that makes sense with the reports. Although the problem surfaced > because the clocktime appears to have slipped on my server, this could > still be an occasional problem for users too. Yes. I knew that once upon the time but it happened not often enough yet to do something about it. -- andreas
