List Archive: gentoo-council
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
>>>>> 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
> 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  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.
 <http://bugs.gentoo.org/264130#c39> and following comments