Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] preserving mtimes
Date: Wed, 07 May 2008 01:35:26
Message-Id: 20080507013518.GB6862@seldon.metaweb.com
In Reply to: Re: [gentoo-dev] preserving mtimes by Ciaran McCreesh
1 On Wed, May 07, 2008 at 01:52:19AM +0100, Ciaran McCreesh wrote:
2 > On Wed, 07 May 2008 00:44:28 +0200
3 > "Marijn Schouten (hkBst)" <hkBst@g.o> wrote:
4 > > and I think that would be the correct thing to do, but either way I'd
5 > > like PMS to specify what should happen wrt to mtimes, so that I can
6 > > rely on that.
7 >
8 > PMS makes no guarantee as to what happens with mtimes, which means you
9 > can't rely upon things happening one way or the other. This is
10 > deliberate -- preserving mtimes leads to all kinds of weirdness on
11 > packages that are generated from a raw tar file rather than from a
12 > build system.
13
14 I'd be curious what weirdness you're referring to, since pkgcore has
15 preserved mtime from the get go.
16
17 Yet to see a single issue from it, although *I* could think of a few
18 instances where it would be problematic- that said, those pkgs already
19 do postinst resetting of mtime to work around portage/paludis
20 resetting mtime, so those issues doesn't appear.
21
22
23 > > Current work-around is tarring up and untarring to preserve mtimes.
24 >
25 > That's not really any good either. The proper solution would be to fix
26 > whatever it is that's mtime-sensitive.
27
28 That's not exactly much of a solution; simplest example, that results
29 in python.eclass:python_mod_compile, invoked during postinst to reset
30 the cached bytecode mtimes (essentially). Aside from this being
31 uncontrolled/untracked access to the live fs, this slows down merges
32 due to redundant work.
33
34 Finally, it also trashes the chksums that the manager records upon
35 merging to the fs- so an mtime/chksum based unmerger can/will orphan
36 those files.
37
38 Frankly, the mtime issue keeps rearing its head and needs killing-
39 it's been an issue for near 4 years even, back in the OSX days we had
40 to rewrite .a TOC's since the linker was mtime aware.
41
42 See no reason to preserve this misfeature. Can't comment on paludis,
43 but it shouldn't be an issue for portage to make the leap from what
44 I've seen source wise.
45
46 ~harring