Danek Duvall <danek.duvall at sun.com> writes: > On Thu, Apr 24, 2008 at 05:44:31PM -0400, Richard Lowe wrote: > >> "Mark J. Nelson" <Mark.J.Nelson at Sun.COM> writes: >> >> >> Webrev is: http://cr.opensolaris.org/~richlowe/scm_480 >> > >> > 480: Wasn't there something about granularity here, too? >> > I.e. seconds, as opposed to something smaller? >> >> Danek and I talked about that, in a brief discussion on the pkg list. >> I'm utterly confused by what he's telling me as compared to what the >> code is doing. >> >> From talking to Danek just now, I think we suspect the current comment >> is correct. I've been thinking about this more closely, and it's >> possible that my understanding of what was said is backwards, if the >> granularity is such that the new mtime is *within* (rather than beyond >> a second), it may not trigger. > > The granularity is on a one-second basis -- that's what's stored in the > .pyc file, and that's what's read off disk, AFAICT. > > However, I think the "either file" part of the comment is incorrect. We > don't need to (and don't in fact) diddle with the mtime of the .pyc file > itself; we only touch the .py file back to the time the .pyc file expects > it to be.
Actually, we adjust both, though as you say, we only really need to deal with the .py, I was shooting for safety. I will adjust the comment to make reality more clear, and if you would like will file a separate bug to not use INS.pyfile for the .pyc? Thanks, -- Rich
