1 |
>>>>> On Mon, 9 Nov 2009, Ciaran McCreesh wrote: |
2 |
|
3 |
> What Portage currently does is, more or less, to preserve mtimes |
4 |
> [...] from every part of the build and merge processes, except for |
5 |
> an arbitrary set of files that it modifies outside of the ebuild's |
6 |
> control. |
7 |
|
8 |
And exactly this should be the guideline: A modified file may have its |
9 |
mtime updated, an unmodified file has its mtime preserved. But for |
10 |
some reason this is not wanted and was countered with arguments such |
11 |
as "the PM could do two passes of rot-13 encryption". |
12 |
|
13 |
> None of these strike me as reasonable solutions, and I am still of |
14 |
> the opinion that this isn't something that should have been rushed |
15 |
> into EAPI 3 |
16 |
|
17 |
The respective bug was opened in March, more than 7 months ago. That's |
18 |
not what I would call "rush". |
19 |
|
20 |
> without people having spent time taking a good look at what all |
21 |
> mtime preservation would be needed to do, what Portage currently |
22 |
> does (since it does not, as some people have claimed, preserve |
23 |
> mtimes) and what should be done about packages that end up |
24 |
> installing files with absurd mtimes. |
25 |
|
26 |
> If guaranteed mtime preservation is a desired feature, we should be |
27 |
> designing it around what developers need, not around what Portage |
28 |
> currently does. |
29 |
|
30 |
What if the two coincide? |
31 |
|
32 |
Ulrich |