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 |