>>>>> On Tue, 31 Mar 2009, Michael Haubenwallner wrote:
> On Mon, 2009-03-30 at 19:14 +0200, Ulrich Mueller wrote:
>> 1. Record two timestamps:
>> before calling pkg_setup, timestamp1;
>> after src_install has completed, timestamp2.
>>
>> 2. After src_install and before merging (the exact time would be
>> implementation dependent), scan ${D} for files having
>> mtime < timestamp1 or mtime > timestamp2.
>> Update their mtimes to timestamp1 or timestamp2, respectively.
>>
>> 3. Otherwise (i.e. for files with timestamp1 <= mtime <= timestamp2),
>> preserve modification times when merging ${D} to ${ROOT}.
Or, even shorter: The basic idea is to preserve the mtimes from ${D}
when merging. Except for "old" mtimes which will be advanced to the
time when the build process began. (And mtimes from the future will
also be fixed, but this case should normally not occur.)
But from discussions in #-dev I conclude that several people would be
happier if just mtimes from ${D} were preserved. In fact, this is the
current Portage and Pkgcore behaviour.
One could think about making step 1 and 2 of above procedure optional
(which was what I had originally in mind, see [1]). Then there would
be no need to change anything in Portage and Pkgcore. Or Portage could
control it via FEATURES, giving the user the choice.
> Maybe this could be done somehow like this, with 'merge time'
> calculation for each file based on above steps 1.-3.:
> * When a to-be-merged file does not exist before, set mtime to
> 'merge time'.
> * When a to-be-merged file does exist already, and its content
> does not change, take the mtime from the already existing file.
> * When a to-be-merged file does exist already, and its content
> does change, set mtime to 'merge time'.
Unfortunately, this will not work. Looking at Lisp again, it may lead
to a fasl file older than the corresponding lisp (imagine that there
could be only a comment change in the source, and the compiled file
would be identical). Also setting mtime to "merge time" will break
some packages (see bug 83877 [2] for an example).
> Maybe this should be done for header files only, or with some black- or
> whitelisting mechanisms, or for files which have mtime<'build time'?
Too complicated, for my taste.
Ulrich
[1] <https://bugs.gentoo.org/show_bug.cgi?id=264130#c12>
[2] <https://bugs.gentoo.org/show_bug.cgi?id=83877>
