On Wed, Nov 07, 2012 at 01:27:33PM +0100, Marc Espie wrote: > Actually, we discussed a possible approach. It looks reasonable to have a > "compile as package" mode (say through an env variable for instance) that > would disable the check and leave a mark in the compiled file that says the > check is not relevant. > > It's as simple as 'store timestamp as 0000 in the .pyc file'...
I guess something like this could fix lang/python, but my worry is that other packages (e.g. possibly some of other dynamically typed languages in ports) might be relying on timestamps. We probably don't notice pkg_delete problems unless they run as root; there may still be performance problems (as it would seem there currently are with lang/python). For example, if we ever get lang/pypy into ports (it languishes in openbsd-wip...), we'd need to do a similar hack as above for it. > Apparently, there are other tendrils elsewhere that make this a bit more > complicated, but for a package system, requiring timestamps to be > consistent makes things MORE brittle, in the presence of NFS, clock-skew, > and various other issues. For instance, one prominent member of the project > does not believe in clock synchronization and does builds over NFS on > machines with wildly inaccurate clocks... The problems I'm thinking about only care about relative timestamps within a package (i.e. comparing the two timestamps within a package for "which file is newer?"). That's a much less stringent requirement, and may even cope well enough with builds from clock-sync deniers? Laurie
