Gentoo Archives: gentoo-council

From: Denis Dupeyron <calchan@g.o>
To: gentoo-council@l.g.o
Subject: Re: [gentoo-council] Re: mtime preservation
Date: Mon, 09 Nov 2009 17:58:45
Message-Id: 7c612fc60911090958q3237b95k433522f76f195e4@mail.gmail.com
In Reply to: Re: [gentoo-council] Re: mtime preservation by Ulrich Mueller
On Mon, Nov 9, 2009 at 8:34 AM, Ciaran McCreesh
<ciaran.mccreesh@××××××××××.com> wrote:
> If guaranteed mtime preservation is a desired feature, we > should be designing it around what developers need, not around what > Portage currently does.
I totally agree with you here. Let's focus on what we need and we'll see about the implementation later. The idea of not doing something because it requires changes to Portage's code is silly. Manpower can and will always be an issue, but it's not a reason for freezing development or not fixing what we think is broken. On Mon, Nov 9, 2009 at 9:36 AM, Ulrich Mueller <ulm@g.o> wrote:
> Which package? sci-electronics/ghdl?
Yes, but it doesn't really matter.
> 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. On Mon, Nov 9, 2009 at 9:53 AM, Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
> 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. If it were me only I'd do what I proposed in my previous email with the precision above about all mtimes being preserved. This gives: 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. 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. Denis.

Replies

Subject Author
Re: [gentoo-council] Re: mtime preservation Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>