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 |