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 15:34:38
Message-Id: 20091109153429.502e272f@snowcone
In Reply to: Re: [gentoo-council] Re: mtime preservation by Denis Dupeyron
On Mon, 9 Nov 2009 08:18:15 -0700
Denis Dupeyron <calchan@g.o> wrote:
> So here are the 2 wordings I propose. > > 1 - All mtimes from the package's sources are preserved until files > are merged to ${ROOT}. In case some mtimes are absurd and/or > unsuitable, they're considered a bug and it's the maintainer's > responsibility to fix them and report back upstream. > > 2 - 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}. > > How's that? Am I missing something?
Neither of those are what Portage currently does. It is my understanding that the Council doesn't want to require any changes to Portage behaviour for this. What Portage currently does is, more or less, to preserve mtimes (but not necessarily sub-second mtimes, even where supported) from every part of the build and merge processes, except for an arbitrary set of files that it modifies outside of the ebuild's control. Examples of such files include, but are not limited to, executables and shared objects. The problem lies in the exceptions. Either we word PMS so vaguely that it's legal for the package manager to clobber any mtime (thus defeating the point of guaranteeing preservation at all), or we include long, convoluted wording describing exactly the files Portage currently alters (thus preventing reasonable-looking future changes), or we make the mtime preservation guarantee only cover a small portion of time such as between pkg_preinst and the merge phase (which disallows some of the things people want to be able to do with mtime preservation). 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 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. -- Ciaran McCreesh

Attachments

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

Replies

Subject Author
Re: [gentoo-council] Re: mtime preservation "Petteri Räty" <betelgeuse@g.o>
Re: [gentoo-council] mtime preservation Ulrich Mueller <ulm@g.o>
Re: [gentoo-council] Re: mtime preservation Ulrich Mueller <ulm@g.o>