Gentoo Archives: gentoo-council

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: Ulrich Mueller <ulm@g.o>
Cc: gentoo-council@l.g.o
Subject: Re: [gentoo-council] mtime preservation
Date: Fri, 20 Nov 2009 00:01:43
Message-Id: 20091119221248.539eedd9@snowmobile
In Reply to: Re: [gentoo-council] mtime preservation by Ulrich Mueller
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]: -- Ciaran McCreesh


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-council] mtime preservation Denis Dupeyron <calchan@g.o>
Re: [gentoo-council] mtime preservation Ulrich Mueller <ulm@g.o>