| 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 |
Archives