>>>>> On Wed, 4 Nov 2009, Ciaran McCreesh wrote:

>> Part of the problem (what you call "insufficient clarity") is that
>> the proposal's original intention was to cover only the merge
>> process, i.e. what takes place after pkg_preinst. Whereas you want
>> to extend it to include everything that is taking place after
>> src_install (for Portage, prepstrip and whatnot).
>> 
>> If you limit it to the final merge process from D to ROOT, then the
>> answer is easy, namely mtimes of all regular files must be
>> preserved.

> What I want is for the proposal to be sufficiently specific that it
> covers exactly what the package manager can and cannot do, and what
> ebuilds can and cannot rely upon happening. If you require mtime
> preservation between pkg_preinst and the merge to /, the package
> manager can just screw things up (by implementing reasonable
> features) elsewhere. It is by no means clear to me that merely
> requiring mtime preservation from after pkg_preinst to before
> pkg_postinst, and allowing arbitrary mtime tinkering elsewhere, is
> what is desired.

Can you try to find a suitable wording? Otherwise, it's not clear to
me how the council could resolve the issue during the next meeting.

(And as my suggested wording [1] caused some unfortunate discussion,
I don't feel like I should come up with a new one myself.)

> As an example for the above, is it legal for a package manager to
> rewrite any mtime that is before the start of the build process if
> it does it after src_install but before pkg_preinst?

So you really want this? ;-) My personal opinion is that it wouldn't
break anything and we could therefore declare it as an allowed QA
measure. And if it takes place before pkg_preinst then the ebuild
could override it in special cases.

But please be aware that the council (October meeting) has voted
against this sort of mtime fixup.

Ulrich

[1] <http://bugs.gentoo.org/264130#c39> and following comments