Gentoo Archives: gentoo-council

From: Denis Dupeyron <calchan@g.o>
To: gentoo-council@l.g.o
Subject: Re: [gentoo-council] Re: mtime preservation
Date: Mon, 09 Nov 2009 17:58:45
Message-Id: 7c612fc60911090958q3237b95k433522f76f195e4@mail.gmail.com
In Reply to: Re: [gentoo-council] Re: mtime preservation by Ulrich Mueller
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.

Replies

Subject Author
Re: [gentoo-council] Re: mtime preservation Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>