Re: [gentoo-council] mtime preservation

[Ciaran McCreesh]

On Tue, 10 Nov 2009 08:07:17 +0100
Ulrich Mueller <ulm@g.o> wrote:
> ,----
> | The package manager must preserve modification times of regular
> files. | This includes files being compressed before merging.
> Exceptions to | this are:
> `----
>
> Now we need to enumerate the exceptions:
>
> ,----
> | * files newly created by the package manager,
> `----
>
> This will cover splitdebug, for example. (And please don't tell me
> that the wording is flawed because the PM could save a file's contents
> in some buffer, then delete the file and create it newly. This would
> be as unreasonable as the rot-13 example.)

Funnily enough... objcopy does its own fancy things with utimes. Last
time I looked it wasn't sub-second aware, though.

> ,----
> | * binary object files being stripped of symbols.
> `----
>
> Anything else missing from above list?

man pages, info pages, things covered by ecompress, arbitrary
documentation, any source code file, probably some others.

> > (thus preventing reasonable-looking future changes), [...]
>
> I don't get the point here. For any future change not covered by the
> list of exceptions, the PM would have to preserve mtime, in spite of
> modifying the file. Why would this prevent doing the change?

Preserving mtime isn't always the right thing to do, though. If the
package manager does something that would invalidate caches, you don't
want it to do so in a way that won't be noticed.

Also, back on the subject of sub-second resolution mtimes... Python
doesn't support them properly thanks to some utter brain damage from
its designers [1]. Files will end up with corrupted sub-second mtimes if
Python is used to set those times, which can again lead to broken
caches. But since not everything Portage merges does use Python to set
sub-second mtimes, this will result in any cache that starts looking at
sub-second resolution mtimes (which will happen -- POSIX considers the
non-sub-second functions deprecated) seeing a mix of valid and subtly
corrupted timestamps.

I honestly don't think we should be going anywhere with this until
Portage is using a mechanism that guarantees correct sub-second
resolution preservation in all cases.

[1]: http://ciaranm.wordpress.com/2009/11/15/this-week-in-python-stupidity-os-stat-os-utime-and-sub-second-timestamps/

-- 
Ciaran McCreesh