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