1 |
On Wed, 4 Nov 2009 16:07:30 +0100 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
> Obviously we cannot guarantee anything below the seconds level because |
4 |
> of limitations in the underlying filesystems or software (e.g., tar |
5 |
> for binpkgs). But is there a reason for limiting it further, i.e. not |
6 |
> preserving sub-second timestamps if they are supported by both |
7 |
> filesystems? |
8 |
|
9 |
So far as I can see, if they're fully supported on both filesystems, |
10 |
Portage sometimes preserves nanosecond-resolution timestamps and |
11 |
sometimes doesn't. So, requiring nanosecond-resolution timestamp |
12 |
preservation where possible will need Portage changes. But not |
13 |
requiring it means we'll go through this whole thing again as packages |
14 |
start using more accurate timestamps for cache validation things (and |
15 |
yes, this will happen -- we've already hit make-related issues on this |
16 |
front). |
17 |
|
18 |
> > * For which files must mtimes be preserved, and which can be |
19 |
> > modified? |
20 |
> |
21 |
> > * Is it the intent of this proposal to prevent package managers from |
22 |
> > automatically rewriting, say, #!/usr/bin/python to |
23 |
> > #!/opt/gentoo/bin/python if prefix is being used? |
24 |
> |
25 |
> Part of the problem (what you call "insufficient clarity") is that the |
26 |
> proposal's original intention was to cover only the merge process, |
27 |
> i.e. what takes place after pkg_preinst. Whereas you want to extend it |
28 |
> to include everything that is taking place after src_install (for |
29 |
> Portage, prepstrip and whatnot). |
30 |
> |
31 |
> If you limit it to the final merge process from D to ROOT, then the |
32 |
> answer is easy, namely mtimes of all regular files must be preserved. |
33 |
|
34 |
What I want is for the proposal to be sufficiently specific that it |
35 |
covers exactly what the package manager can and cannot do, and what |
36 |
ebuilds can and cannot rely upon happening. If you require mtime |
37 |
preservation between pkg_preinst and the merge to /, the package |
38 |
manager can just screw things up (by implementing reasonable features) |
39 |
elsewhere. It is by no means clear to me that merely requiring mtime |
40 |
preservation from after pkg_preinst to before pkg_postinst, and |
41 |
allowing arbitrary mtime tinkering elsewhere, is what is desired. |
42 |
|
43 |
As an example for the above, is it legal for a package manager to |
44 |
rewrite any mtime that is before the start of the build process if it |
45 |
does it after src_install but before pkg_preinst? |
46 |
|
47 |
-- |
48 |
Ciaran McCreesh |