1 |
On Tue, 10 Nov 2009 08:07:17 +0100 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
> ,---- |
4 |
> | The package manager must preserve modification times of regular |
5 |
> files. | This includes files being compressed before merging. |
6 |
> Exceptions to | this are: |
7 |
> `---- |
8 |
> |
9 |
> Now we need to enumerate the exceptions: |
10 |
> |
11 |
> ,---- |
12 |
> | * files newly created by the package manager, |
13 |
> `---- |
14 |
> |
15 |
> This will cover splitdebug, for example. (And please don't tell me |
16 |
> that the wording is flawed because the PM could save a file's contents |
17 |
> in some buffer, then delete the file and create it newly. This would |
18 |
> be as unreasonable as the rot-13 example.) |
19 |
|
20 |
Funnily enough... objcopy does its own fancy things with utimes. Last |
21 |
time I looked it wasn't sub-second aware, though. |
22 |
|
23 |
> ,---- |
24 |
> | * binary object files being stripped of symbols. |
25 |
> `---- |
26 |
> |
27 |
> Anything else missing from above list? |
28 |
|
29 |
man pages, info pages, things covered by ecompress, arbitrary |
30 |
documentation, any source code file, probably some others. |
31 |
|
32 |
> > (thus preventing reasonable-looking future changes), [...] |
33 |
> |
34 |
> I don't get the point here. For any future change not covered by the |
35 |
> list of exceptions, the PM would have to preserve mtime, in spite of |
36 |
> modifying the file. Why would this prevent doing the change? |
37 |
|
38 |
Preserving mtime isn't always the right thing to do, though. If the |
39 |
package manager does something that would invalidate caches, you don't |
40 |
want it to do so in a way that won't be noticed. |
41 |
|
42 |
Also, back on the subject of sub-second resolution mtimes... Python |
43 |
doesn't support them properly thanks to some utter brain damage from |
44 |
its designers [1]. Files will end up with corrupted sub-second mtimes if |
45 |
Python is used to set those times, which can again lead to broken |
46 |
caches. But since not everything Portage merges does use Python to set |
47 |
sub-second mtimes, this will result in any cache that starts looking at |
48 |
sub-second resolution mtimes (which will happen -- POSIX considers the |
49 |
non-sub-second functions deprecated) seeing a mix of valid and subtly |
50 |
corrupted timestamps. |
51 |
|
52 |
I honestly don't think we should be going anywhere with this until |
53 |
Portage is using a mechanism that guarantees correct sub-second |
54 |
resolution preservation in all cases. |
55 |
|
56 |
[1]: http://ciaranm.wordpress.com/2009/11/15/this-week-in-python-stupidity-os-stat-os-utime-and-sub-second-timestamps/ |
57 |
|
58 |
-- |
59 |
Ciaran McCreesh |