Gentoo Archives: gentoo-council

From: Ulrich Mueller <ulm@g.o>
To: Denis Dupeyron <calchan@g.o>
Cc: gentoo-council@l.g.o
Subject: Re: [gentoo-council] Re: mtime preservation
Date: Mon, 09 Nov 2009 16:36:51
In Reply to: Re: [gentoo-council] Re: mtime preservation by Denis Dupeyron
>>>>> On Mon, 9 Nov 2009, Denis Dupeyron wrote:
> Let the clueless dev that I am summarize the situation. Please > correct me if I'm wrong, I think that will help more people than > just me. In the end I'll propose 2 wordings for PMS.
> I understand that the issue with requiring mtime preservation is > that after unpacking the tarball(s) some files can have absurd > dates, like January 1st 1970 or else. One easy solution to this > would be to reset mtimes at merge time which will take care of > everything. However, I know of a package which requires mtime > preservation from src_compile to the moment it's merged to ${ROOT}.
Which package? sci-electronics/ghdl?
> And if there's a package like this in my very small corner of Gentoo > there must be more elsewhere, and there probably will be more in the > future.
The "absurd dates" issue would have been addressed by option B in <>. This was up for vote at the last council meeting, but wasn't chosen.
> 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?
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). Ulrich


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