Gentoo Archives: gentoo-council

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-council@l.g.o
Subject: Re: [gentoo-council] Re: mtime preservation
Date: Mon, 09 Nov 2009 18:14:28
Message-Id: 20091109181418.03e1ee20@snowcone
In Reply to: Re: [gentoo-council] Re: mtime preservation by Denis Dupeyron
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


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-council] Re: mtime preservation Denis Dupeyron <calchan@g.o>