1 |
On Mon, 9 Nov 2009 10:58:43 -0700 |
2 |
Denis Dupeyron <calchan@g.o> wrote: |
3 |
> > Hm, the idea was something like wording 1, but more details should |
4 |
> > be added since there are also files that are modified by Portage |
5 |
> > (e.g. binaries being stripped). |
6 |
> |
7 |
> If we decide we want to preserve mtimes I'm in favor of something |
8 |
> simple such as: *all* mtimes are being preserved, period, whether the |
9 |
> package manager modifies them or not. If the binaries are being |
10 |
> stripped their original mtimes can certainly be restored, can't they? |
11 |
> This would make for a much more reliable and manageable behavior. |
12 |
|
13 |
It's doable. It's just that all mtimes being preserved is clearly wrong |
14 |
for the 1 Jan 1970 cases. |
15 |
|
16 |
> > And it was left out of EAPI 3 originally because no appropriate |
17 |
> > solution had been found. |
18 |
> |
19 |
> Any chance you can tell us what you would propose disregarding what |
20 |
> the council would think of it or want to do and whether Portage would |
21 |
> have the feature or not already? It doesn't have to be fully fleshed |
22 |
> out and there can be blanks where you don't have the right answers. |
23 |
> And don't bother about implementation but just about the need. I would |
24 |
> encourage anybody who's interested to do the same. |
25 |
|
26 |
My understanding is that: |
27 |
|
28 |
* Most ebuilds don't care what happens, but a small number want to be |
29 |
able to guarantee mtime preservation for a subset of what they |
30 |
install. Those that care may prefer to handle preservation in various |
31 |
different functions. |
32 |
|
33 |
* Changing mtimes on source trees is likely problematic with autotooled |
34 |
packages. |
35 |
|
36 |
* Preserving mtimes unconditionally leads to silly mtimes being |
37 |
preserved. |
38 |
|
39 |
Thus, I would let EAPI 4 ebuilds call dopreservemtimes (with an API |
40 |
similar to docompress) in both src_install and pkg_preinst. Doing so |
41 |
would instruct the package manager that it must preserve mtimes |
42 |
(including subsecond, if supported on the filesystem) for a particular |
43 |
set of paths, even if doing so means no stripping etc. All other mtimes |
44 |
may be rewritten as the package manager sees fit, and from EAPI 4 |
45 |
onwards must be rewritten at merge time for anything predating the |
46 |
start of the build. |
47 |
|
48 |
> All mtimes from the package's sources are reset to current time |
49 |
> between the src_unpack phase and the next one. That is before |
50 |
> src_configure when EAPI<2 and before src_prepare when EAPI>=2. mtimes |
51 |
> are then preserved until files are merged to ${ROOT}. If the package |
52 |
> manager modifies a file on its own then the original mtime needs to be |
53 |
> restored. |
54 |
|
55 |
I have a sneaking suspicion that this will cause horrible complications |
56 |
for generated Makefiles and the like... |
57 |
|
58 |
> About nanosecond resolution I think we should enforce it where |
59 |
> possible and progressively deprecate those versions of package |
60 |
> managers and their supporting libraries which do not allow for |
61 |
> nanosecond resolution. I have no idea how technically feasible that is |
62 |
> though. My fear is that in case we want to preserve mtimes and that a |
63 |
> given package relies on nanosecond resolution then not supporting the |
64 |
> latter is like not preserving mtimes. |
65 |
|
66 |
My understanding of the Python documentation is that they've royally |
67 |
buggered the whole thing up by overloading stat.st_mtime and utimes on |
68 |
floating point values for nanosecond-resolution timestamps, which |
69 |
doesn't work because a float isn't precise enough to hold ten decimal |
70 |
digits to the left of the decimal point and nine to the right... |
71 |
|
72 |
-- |
73 |
Ciaran McCreesh |