Re: [gentoo-council] Re: mtime preservation

[Ciaran McCreesh]

On Mon, 9 Nov 2009 10:58:43 -0700
Denis Dupeyron <calchan@g.o> wrote:
> > Hm, the idea was something like wording 1, but more details should
> > be added since there are also files that are modified by Portage
> > (e.g. binaries being stripped).
>
> If we decide we want to preserve mtimes I'm in favor of something
> simple such as: *all* mtimes are being preserved, period, whether the
> package manager modifies them or not. If the binaries are being
> stripped their original mtimes can certainly be restored, can't they?
> This would make for a much more reliable and manageable behavior.

It's doable. It's just that all mtimes being preserved is clearly wrong
for the 1 Jan 1970 cases.

> > And it was left out of EAPI 3 originally because no appropriate
> > solution had been found.
>
> Any chance you can tell us what you would propose disregarding what
> the council would think of it or want to do and whether Portage would
> have the feature or not already? It doesn't have to be fully fleshed
> out and there can be blanks where you don't have the right answers.
> And don't bother about implementation but just about the need. I would
> encourage anybody who's interested to do the same.

My understanding is that:

* Most ebuilds don't care what happens, but a small number want to be
  able to guarantee mtime preservation for a subset of what they
  install. Those that care may prefer to handle preservation in various
  different functions.

* Changing mtimes on source trees is likely problematic with autotooled
  packages.

* Preserving mtimes unconditionally leads to silly mtimes being
  preserved.

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.

> All mtimes from the package's sources are reset to current time
> between the src_unpack phase and the next one. That is before
> src_configure when EAPI<2 and before src_prepare when EAPI>=2. mtimes
> are then preserved until files are merged to ${ROOT}. If the package
> manager modifies a file on its own then the original mtime needs to be
> restored.

I have a sneaking suspicion that this will cause horrible complications
for generated Makefiles and the like...

> About nanosecond resolution I think we should enforce it where
> possible and progressively deprecate those versions of package
> managers and their supporting libraries which do not allow for
> nanosecond resolution. I have no idea how technically feasible that is
> though. My fear is that in case we want to preserve mtimes and that a
> given package relies on nanosecond resolution then not supporting the
> latter is like not preserving mtimes.

My understanding of the Python documentation is that they've royally
buggered the whole thing up by overloading stat.st_mtime and utimes on
floating point values for nanosecond-resolution timestamps, which
doesn't work because a float isn't precise enough to hold ten decimal
digits to the left of the decimal point and nine to the right...

-- 
Ciaran McCreesh