1 |
On Mon, Nov 9, 2009 at 8:34 AM, Ciaran McCreesh |
2 |
<ciaran.mccreesh@××××××××××.com> wrote: |
3 |
> If guaranteed mtime preservation is a desired feature, we |
4 |
> should be designing it around what developers need, not around what |
5 |
> Portage currently does. |
6 |
|
7 |
I totally agree with you here. Let's focus on what we need and we'll |
8 |
see about the implementation later. The idea of not doing something |
9 |
because it requires changes to Portage's code is silly. Manpower can |
10 |
and will always be an issue, but it's not a reason for freezing |
11 |
development or not fixing what we think is broken. |
12 |
|
13 |
On Mon, Nov 9, 2009 at 9:36 AM, Ulrich Mueller <ulm@g.o> wrote: |
14 |
> Which package? sci-electronics/ghdl? |
15 |
|
16 |
Yes, but it doesn't really matter. |
17 |
|
18 |
> Hm, the idea was something like wording 1, but more details should be |
19 |
> added since there are also files that are modified by Portage (e.g. |
20 |
> binaries being stripped). |
21 |
|
22 |
If we decide we want to preserve mtimes I'm in favor of something |
23 |
simple such as: *all* mtimes are being preserved, period, whether the |
24 |
package manager modifies them or not. If the binaries are being |
25 |
stripped their original mtimes can certainly be restored, can't they? |
26 |
This would make for a much more reliable and manageable behavior. |
27 |
|
28 |
On Mon, Nov 9, 2009 at 9:53 AM, Ciaran McCreesh |
29 |
<ciaran.mccreesh@××××××××××.com> wrote: |
30 |
> And it was left out of EAPI 3 originally because no appropriate solution |
31 |
> had been found. |
32 |
|
33 |
Any chance you can tell us what you would propose disregarding what |
34 |
the council would think of it or want to do and whether Portage would |
35 |
have the feature or not already? It doesn't have to be fully fleshed |
36 |
out and there can be blanks where you don't have the right answers. |
37 |
And don't bother about implementation but just about the need. I would |
38 |
encourage anybody who's interested to do the same. |
39 |
|
40 |
If it were me only I'd do what I proposed in my previous email with |
41 |
the precision above about all mtimes being preserved. This gives: |
42 |
|
43 |
All mtimes from the package's sources are reset to current time |
44 |
between the src_unpack phase and the next one. That is before |
45 |
src_configure when EAPI<2 and before src_prepare when EAPI>=2. mtimes |
46 |
are then preserved until files are merged to ${ROOT}. If the package |
47 |
manager modifies a file on its own then the original mtime needs to be |
48 |
restored. |
49 |
|
50 |
About nanosecond resolution I think we should enforce it where |
51 |
possible and progressively deprecate those versions of package |
52 |
managers and their supporting libraries which do not allow for |
53 |
nanosecond resolution. I have no idea how technically feasible that is |
54 |
though. My fear is that in case we want to preserve mtimes and that a |
55 |
given package relies on nanosecond resolution then not supporting the |
56 |
latter is like not preserving mtimes. |
57 |
|
58 |
Denis. |