On 11/19/10 20:16, Norm Jacobs wrote:
On 11/19/10 01:30 PM, Danek Duvall wrote:
Norm Jacobs wrote:
Without setting timestamps consistently across installations, tools that
compare timestamps to determine what to do don't work at intended. For
example, make(1). On a single installed environment, this generally
isn't a problem. When you want to distribute work across machines and/or
use zones, the inconsistent timestamps can be a problem.
Could you give a more specific example? It seems to me that if a file
changes on a machine, any target would immediately be out of date with
respect to that file, regardless of its timestamp, and so you'd want the
timestamp to reflect that -- have the current time. It seems sketchy to
compare timestamps on individual files across systems, anyway.
Ok, In this case, I installed this system back on March 2nd and then
created a zone on July 8th with the same bits.
home% ls -l /usr/include/zlib.h
-rw-r--r-- 1 root bin 66188 Mar 2 2010 /usr/include/zlib.h
home% pfexec zlogin -S zone-1 ls -l /usr/include/zlib.h
-rw-r--r-- 1 root bin 66188 Jul 8 14:21 /usr/include/zlib.h
home% sum /usr/include/zlib.h
58810 130 /usr/include/zlib.h
home% pfexec zlogin -S zone-1 sum /usr/include/zlib.h
58810 130 /usr/include/zlib.h
The bits were installed from the same source just at different times.
What I want is the timestamp of a file to reflect the time it was built
and/or packaged when I install it, not the time that I install it. That
way if my makefile contains:
foo.o: /usr/include/zlib.h
I will know whether I need to rebuild foo.o regardless of whether or not
I just constructed a new zone or logged into a different system.
Worthy of logging a bug here to capture this information and then take
the appropriate action ?
It would appear that when a system is reinstalled it should have the
same attributes as it had when it was first installed in case there
are time dependent applications that need to run (backups ?)
bart(1M) will use the mtime and will report an error on the mtime when
doing the compare.
Thanks
pete
-Norm
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
