1 |
I'm going to try and sum up the situation of the thread started in |
2 |
[1]. Feel free to correct me or add to the summary in replies. |
3 |
|
4 |
There seems to be two main ideas. I have removed the authors' name in |
5 |
quotes below in order to make sure we talk about the ideas and not who |
6 |
proposed them. |
7 |
|
8 |
1- All packages are treated equally. Some files have their mtime |
9 |
preserved, some don't. We need to agree on what files have their mtime |
10 |
preserved and at what phase the mtime is frozen. What we seemed to |
11 |
have agreed on is that the wording in PMS needs to be unambiguous |
12 |
enough that it doesn't defeat the purpose. Here's a first proposition: |
13 |
|
14 |
"The package manager must preserve modification times of regular files. |
15 |
This includes files being compressed before merging. Exceptions to |
16 |
this are: |
17 |
|
18 |
(Now we need to enumerate the exceptions:) |
19 |
|
20 |
* files newly created by the package manager, |
21 |
(This will cover splitdebug, for example. (And please don't tell me |
22 |
that the wording is flawed because the PM could save a file's contents |
23 |
in some buffer, then delete the file and create it newly. This would |
24 |
be as unreasonable as the rot-13 example.) ) |
25 |
|
26 |
* binary object files being stripped of symbols. |
27 |
|
28 |
(Anything else missing from above list?)" |
29 |
|
30 |
|
31 |
2- Here's the second idea, shamelessly pasted (note that it says EAPI4 |
32 |
below instead of EAPI3 but this is irrelevant to the idea): |
33 |
|
34 |
"Thus, I would let EAPI 4 ebuilds call dopreservemtimes (with an API |
35 |
similar to docompress) in both src_install and pkg_preinst. Doing so |
36 |
would instruct the package manager that it must preserve mtimes |
37 |
(including subsecond, if supported on the filesystem) for a particular |
38 |
set of paths, even if doing so means no stripping etc. All other mtimes |
39 |
may be rewritten as the package manager sees fit, and from EAPI 4 |
40 |
onwards must be rewritten at merge time for anything predating the |
41 |
start of the build." |
42 |
|
43 |
In both cases nanosecond resolution may be required and is a problem |
44 |
due to python. The following workaround can be used until the |
45 |
nanosecond issue is fixed in python: |
46 |
|
47 |
"Alternatively, we could simply make portage spawn the mv binary |
48 |
whenever rename fails (it fails when the source and destination are |
49 |
on different devices). Although it's relatively slow, it should |
50 |
solve the problem." |
51 |
|
52 |
My intention is to ask the council to vote on which method is |
53 |
preferable in two weeks. I will also ask the council on whether we |
54 |
still want mtime preservation for EAPI3 or if we now think it's better |
55 |
to push it to EAPI4. Please discuss. |
56 |
|
57 |
Denis. |
58 |
|
59 |
[1] http://archives.gentoo.org/gentoo-council/msg_becc15a2882cc7e4f1079b2f9f4dcaad.xml |