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