Gentoo Archives: gentoo-council

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-council@l.g.o
Subject: Re: [gentoo-council] Re: mtime preservation
Date: Mon, 09 Nov 2009 15:34:38
Message-Id: 20091109153429.502e272f@snowcone
In Reply to: Re: [gentoo-council] Re: mtime preservation by Denis Dupeyron
1 On Mon, 9 Nov 2009 08:18:15 -0700
2 Denis Dupeyron <calchan@g.o> wrote:
3 > So here are the 2 wordings I propose.
4 >
5 > 1 - All mtimes from the package's sources are preserved until files
6 > are merged to ${ROOT}. In case some mtimes are absurd and/or
7 > unsuitable, they're considered a bug and it's the maintainer's
8 > responsibility to fix them and report back upstream.
9 >
10 > 2 - All mtimes from the package's sources are reset to current time
11 > between the src_unpack phase and the next one. That is before
12 > src_configure when EAPI<2 and before src_prepare when EAPI>=2. mtimes
13 > are then preserved until files are merged to ${ROOT}.
14 >
15 > How's that? Am I missing something?
16
17 Neither of those are what Portage currently does. It is my
18 understanding that the Council doesn't want to require any changes to
19 Portage behaviour for this.
20
21 What Portage currently does is, more or less, to preserve mtimes (but
22 not necessarily sub-second mtimes, even where supported) from every
23 part of the build and merge processes, except for an arbitrary set of
24 files that it modifies outside of the ebuild's control. Examples of
25 such files include, but are not limited to, executables and shared
26 objects.
27
28 The problem lies in the exceptions. Either we word PMS so vaguely that
29 it's legal for the package manager to clobber any mtime (thus defeating
30 the point of guaranteeing preservation at all), or we include long,
31 convoluted wording describing exactly the files Portage currently
32 alters (thus preventing reasonable-looking future changes), or we make
33 the mtime preservation guarantee only cover a small portion of time
34 such as between pkg_preinst and the merge phase (which disallows some
35 of the things people want to be able to do with mtime preservation).
36
37 None of these strike me as reasonable solutions, and I am still of the
38 opinion that this isn't something that should have been rushed into
39 EAPI 3 without people having spent time taking a good look at what all
40 mtime preservation would be needed to do, what Portage currently does
41 (since it does not, as some people have claimed, preserve mtimes) and
42 what should be done about packages that end up installing files with
43 absurd mtimes. If guaranteed mtime preservation is a desired feature, we
44 should be designing it around what developers need, not around what
45 Portage currently does.
46
47 --
48 Ciaran McCreesh

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-council] Re: mtime preservation "Petteri Räty" <betelgeuse@g.o>
Re: [gentoo-council] Re: mtime preservation Ulrich Mueller <ulm@g.o>
Re: [gentoo-council] mtime preservation Ulrich Mueller <ulm@g.o>