[gentoo-dev] mtime preservation

[Denis Dupeyron <calchan@gentoo.org>]

I'm going to try and sum up the situation of the thread started in
[1]. Feel free to correct me or add to the summary in replies.

There seems to be two main ideas. I have removed the authors' name in
quotes below in order to make sure we talk about the ideas and not who
proposed them.

1- All packages are treated equally. Some files have their mtime
preserved, some don't. We need to agree on what files have their mtime
preserved and at what phase the mtime is frozen. What we seemed to
have agreed on is that the wording in PMS needs to be unambiguous
enough that it doesn't defeat the purpose. Here's a first proposition:

"The package manager must preserve modification times of regular files.
This includes files being compressed before merging. Exceptions to
this are:

(Now we need to enumerate the exceptions:)

* files newly created by the package manager,
(This will cover splitdebug, for example. (And please don't tell me
that the wording is flawed because the PM could save a file's contents
in some buffer, then delete the file and create it newly. This would
be as unreasonable as the rot-13 example.) )

* binary object files being stripped of symbols.

(Anything else missing from above list?)"


2- Here's the second idea, shamelessly pasted (note that it says EAPI4
below instead of EAPI3 but this is irrelevant to the idea):

"Thus, I would let EAPI 4 ebuilds call dopreservemtimes (with an API
similar to docompress) in both src_install and pkg_preinst. Doing so
would instruct the package manager that it must preserve mtimes
(including subsecond, if supported on the filesystem) for a particular
set of paths, even if doing so means no stripping etc. All other mtimes
may be rewritten as the package manager sees fit, and from EAPI 4
onwards must be rewritten at merge time for anything predating the
start of the build."

In both cases nanosecond resolution may be required and is a problem
due to python. The following workaround can be used until the
nanosecond issue is fixed in python:

"Alternatively, we could simply make portage spawn the mv binary
whenever rename fails (it fails when the source and destination are
on different devices). Although it's relatively slow, it should
solve the problem."

My intention is to ask the council to vote on which method is
preferable in two weeks. I will also ask the council on whether we
still want mtime preservation for EAPI3 or if we now think it's better
to push it to EAPI4. Please discuss.

Denis.

[1] http://archives.gentoo.org/gentoo-council/msg_becc15a2882cc7e4f1079b2f9f4dcaad.xml