Gentoo Archives: gentoo-council

From: Ulrich Mueller <ulm@g.o>
To: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
Cc: gentoo-council@l.g.o
Subject: Re: [gentoo-council] mtime preservation
Date: Tue, 10 Nov 2009 07:07:20
Message-Id: 19193.4389.637969.727075@a1i15.kph.uni-mainz.de
In Reply to: Re: [gentoo-council] Re: mtime preservation by Ciaran McCreesh
1 Coming back again to your previous posting.
2
3 >>>>> On Mon, 9 Nov 2009, Ciaran McCreesh wrote:
4
5 > The problem lies in the exceptions. Either we word PMS so vaguely
6 > that it's legal for the package manager to clobber any mtime (thus
7 > defeating the point of guaranteeing preservation at all),
8
9 Agreed. This is not what is wanted.
10
11 > or we include long, convoluted wording describing exactly the files
12 > Portage currently alters
13
14 Hm, maybe this isn't as bad as it seems:
15
16 ,----
17 | The package manager must preserve modification times of regular files.
18 | This includes files being compressed before merging. Exceptions to
19 | this are:
20 `----
21
22 Now we need to enumerate the exceptions:
23
24 ,----
25 | * files newly created by the package manager,
26 `----
27
28 This will cover splitdebug, for example. (And please don't tell me
29 that the wording is flawed because the PM could save a file's contents
30 in some buffer, then delete the file and create it newly. This would
31 be as unreasonable as the rot-13 example.)
32
33 ,----
34 | * binary object files being stripped of symbols.
35 `----
36
37 Anything else missing from above list?
38
39 > (thus preventing reasonable-looking future changes), [...]
40
41 I don't get the point here. For any future change not covered by the
42 list of exceptions, the PM would have to preserve mtime, in spite of
43 modifying the file. Why would this prevent doing the change?
44
45 Ulrich

Replies

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