EAPI 3 to Specify “Auto Space like Word 95”

When Microsoft was trying to get OOXML standardised, it received all kinds of flak for including a feature described as “auto space like Word 95”. Unfortunately, the Gentoo Council has just done the same thing for EAPI 3.

Historically, Portage would always clobber a package’s mtimes when merging. This wasn’t really a problem, because nothing relied upon it. Paludis carefully copied this behaviour.

Later on, Portage was changed to more or less preserve file mtimes, but it would sometimes corrupt those mtimes thanks to deficiencies in Python. This is where things started to get messy.

People began writing ebuilds that relied upon mtimes being preserved exactly. Because corruption of the seconds part of mtimes was relatively rare, and because most programs don’t yet make use of nanosecond-resolution timestamps (which were introduced in POSIX 2008), and because invalid bytecode-compiled files are usually silently ignored, this would usually work most of the time, except when it didn’t, or when people were using older Portage versions, or when people were using Paludis.

To solve this, mtime preservation was proposed for EAPI 3. Unfortunately, what ended up being voted in was to “make PMS specify exactly what Portage does”. Assuming “what Portage does” refers to what Portage did at the time the Council vote was held, this means that ebuild authors should note the following:

• The seconds part of mtimes will be preserved, except if the build filesystem supports nanosecond-resolution timestamps, in which case the seconds part of mtimes may sometimes be one higher than they should be.
• The nanoseconds part of mtimes may either be preserved exactly, or set to zero, or rounded to some arbitrary number of digits, with some of those digits being wrong.
• It will now be your responsibility to ensure that packages don’t merge files with silly timestamps (such as when packages don’t use a Makefile to install things, but just cp an extracted tarball’s contents to DESTDIR).

Or, in other words, you still can’t rely upon mtime preservation, but the package manager must guarantee that your code will only sometimes break horribly, and that such breakages will be extremely difficult to reproduce consistently (unless your code uses st_mtim instead of st_mtime, as per newer POSIX, in which case it will break most times but not all of the time).