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: Ciaran McCreesh <ciaran.mccreesh@...>
Subject: Re: Re: mtime preservation
Date: Mon, 9 Nov 2009 15:34:29 +0000
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
Attachment:
signature.asc (PGP signature)
Replies:
Re: mtime preservation
-- Ulrich Mueller
Re: Re: mtime preservation
-- Ulrich Mueller
Re: Re: mtime preservation
-- Petteri R├Ąty
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
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.