Re: [gentoo-dev] mtime preservation

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 3780 bytes --]

On Mon, 23 Nov 2009 15:19:00 -0800
Brian Harring <ferringb@gmail.com> wrote:
> Someone mind explaining to me why we're making mtime preservation so 
> nasty?  Having to enumerate every pathway that requires mtime 
> preservation is pretty arduous for the ebuild dev, meaning it's 
> unlikely they'll get it right, leading to bugs.

It's not in the least bit nasty. It's requiring people to be explicit
about special requirements.

> The thing I'm not understanding here is that pkgcore since day one
> has preserved mtime- I've yet to see any complaints about that nor
> any issues caused by it.  Portage shifted over a year or two back,
> same thing, haven't heard complaints.

You can't have been listening very hard, then. The complaint is that it
results in files with dumb mtimes being merged to /.

> I know it won't fly, but realistically stating "the package manager 
> must preserve mtime- if there are instances where it does not (due to 
> some feature, perhaps splitdebug or some form of compression) it is 
> the package managers responsibility to ensure this does not break the 
> ebuilds resultant merge/runtime invocation".
> 
> Via such wording an exemption is created and it's made clear it's the 
> managers responsibility to keep things playing nice... if the manager 
> can't do that, then the feature/functionality that is changing the 
> mtime (resulting in the pkg on disk failing) must be fixed or 
> disabled.
> 
> The nice thing about this wording is that it basically matches what 
> the case is now, and what has worked for quite a few years.

Wording such as that just isn't suitable for a specification. It
requires implementers to guess what future ebuilds are going to
rely upon (and ebuilds regularly do rely upon weird quirks), and makes
it impossible to produce a package manager that can be shown to be
compliant.

> > In both cases nanosecond resolution may be required and is a problem
> > due to python. The following workaround can be used until the
> > nanosecond issue is fixed in python:
> 
> It'd be nice if someone enumerated merge scenarios where nanosecond 
> resolution is actually required.  Seems like a white elephant to me, 
> especially in combination w/ the fact that the target fs may not 
> support nanosecond.

POSIX considers several of the non-nanosecond resolution calls to be
deprecated. Going "la la la I can't hear you!" because Python happens
to have utterly screwed this up is just going to lead to problems when
programs start using sub-second validity checks -- 'make' already does,
and it's given rise to various build-directory-related issues.

> Basically, if it's required the manager support nanosecond resolution 
> for merging, ebuilds must be able to rely on that- end result, any 
> merging to FS's that do not support nanosecond (this includes the 
> intermediate ${D}) are no longer supported.  Unless I'm missing 
> something, iso-9660 doesn't look to support nanosecond resolution.  
> Beyond that, does cramfs/squashfs?  If not, taking this to the 
> logical conclusion the livecds aren't technically supported as a
> merge environment.

No, we're after a requirement that the package manager must not screw up
nanosecond-resolution timestamps, and must not partially preserve and
partially not preserve them.

> > "Alternatively, we could simply make portage spawn the mv binary
> > whenever rename fails (it fails when the source and destination are
> > on different devices). Although it's relatively slow, it should
> > solve the problem."
> 
> Yeah... no.  Slowing down the main manager for a thereotical edge
> case doesn't seem particularly useful to me ;)

...or you could just fix Python.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]