On Mon, Nov 9, 2009 at 8:34 AM, Ciaran McCreesh
<ciaran.mccreesh@...> 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@...> 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.