On Mon, 23 Nov 2009 15:19:00 -0800 Brian Harring <ferri...@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
signature.asc
Description: PGP signature
