Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-council
Navigation:
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-council@g.o
From: Denis Dupeyron <calchan@g.o>
Subject: Re: Re: mtime preservation
Date: Mon, 9 Nov 2009 10:58:43 -0700
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.


Replies:
Re: Re: mtime preservation
-- Ciaran McCreesh
References:
Agenda (draft) for November meeting 2009-11-09
-- Ulrich Mueller
Re: Agenda (draft) for November meeting 2009-11-09
-- Ciaran McCreesh
mtime preservation (was: Agenda (draft) for November meeting 2009-11-09)
-- Ulrich Mueller
Re: mtime preservation (was: Agenda (draft) for November meeting 2009-11-09)
-- Ciaran McCreesh
Re: mtime preservation
-- Ulrich Mueller
Re: Re: mtime preservation
-- Ciaran McCreesh
Re: Re: mtime preservation
-- Denis Dupeyron
Re: Re: mtime preservation
-- Ulrich Mueller
Navigation:
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: mtime preservation
Next by thread:
Re: Re: mtime preservation
Previous by date:
Re: Re: mtime preservation
Next by date:
Re: Re: mtime preservation


Updated Nov 13, 2011

Summary: Archive of the gentoo-council mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.