On Mon, Nov 23, 2009 at 11:49:25AM -0700, Denis Dupeyron wrote:
> 2- Here's the second idea, shamelessly pasted (note that it says EAPI4
> below instead of EAPI3 but this is irrelevant to the idea):
> 
> "Thus, I would let EAPI 4 ebuilds call dopreservemtimes (with an API
> similar to docompress) in both src_install and pkg_preinst. Doing so
> would instruct the package manager that it must preserve mtimes
> (including subsecond, if supported on the filesystem) for a particular
> set of paths, even if doing so means no stripping etc. All other mtimes
> may be rewritten as the package manager sees fit, and from EAPI 4
> onwards must be rewritten at merge time for anything predating the
> start of the build."

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.

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.

The thing that's bugging me about this whole discussion is that we're 
spending more time focusing on stupid things the manager could do to 
(basically intentionally) screw up the mtime preservation.

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.


> 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.

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.

Essentially If we're going to require the manager support NS 
resolution w/out requiring all FS's involved support NS level 
resolution, in reality ebuilds can't rely on NS level resolution.  

Thus drop the requirement since we gain nothing from it- if it's not a 
gurantee ebuilds can rely on then they should be writing to the lowest 
common denominator- second level resolution.  That may sound heinous, 
but it's also being realistic.


> "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 ;)

~harring