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
