Re: [gentoo-council] Re: mtime preservation

[Ciaran McCreesh]

On Mon, 9 Nov 2009 17:37:26 +0100
Ulrich Mueller <ulm@g.o> wrote:
> > What Portage currently does is, more or less, to preserve mtimes
> > [...] from every part of the build and merge processes, except for
> > an arbitrary set of files that it modifies outside of the ebuild's
> > control.
>
> And exactly this should be the guideline: A modified file may have its
> mtime updated, an unmodified file has its mtime preserved. But for
> some reason this is not wanted and was countered with arguments such
> as "the PM could do two passes of rot-13 encryption".

It's not wanted because it's utterly useless as a specification. It
means ebuilds can't rely upon any file having its mtime preserved,
because a package manager can decide, reasonably or otherwise, to
modify any file it likes.

The double-rot-13 argument is merely a compact illustration of why
leaving it open is unworkable. If you prefer a more subtle argument,
consider "the package manager might want to rewrite #!/usr/bin/python
lines automatically in Prefix environments", but be aware that any
example of that nature is prone to being sidetracked into arguments
about "but Prefix won't do it that way", entirely missing the wider
point.

Now, you could claim, as you do, that the proposal should only matter
for pkg_preinst to merge mtime preservation, and so rewriting of this
kind is fine if it's done straight after src_install. But we have yet
to establish whether every ebuild mtime-related operation is best done
exclusively in pkg_preinst (and this is far from a straight-forward
question, when you have to start thinking about binaries and about
cleanup), and it's not safe to jump to the conclusion that allowing the
package manager to modify things straight after src_install is safe and
in line with what best suits developers.

> > None of these strike me as reasonable solutions, and I am still of
> > the opinion that this isn't something that should have been rushed
> > into EAPI 3
>
> The respective bug was opened in March, more than 7 months ago. That's
> not what I would call "rush".

And it was left out of EAPI 3 originally because no appropriate solution
had been found. As you're aware, there's a finite amount of time that
can be spent working on these things, and thus-far not enough of that
time has been devoted to turning this into a solvable problem.

> > without people having spent time taking a good look at what all
> > mtime preservation would be needed to do, what Portage currently
> > does (since it does not, as some people have claimed, preserve
> > mtimes) and what should be done about packages that end up
> > installing files with absurd mtimes.
>
> > If guaranteed mtime preservation is a desired feature, we should be
> > designing it around what developers need, not around what Portage
> > currently does.
>
> What if the two coincide?

They don't. I have yet to see any argument in favour of random and
inconsistent clobbering of sub-second mtimes, and I have yet to see any
argument in favour of files with a timestamp of 1 Jan 1970 being merged
to /, other than that Portage currently does both of those things.

-- 
Ciaran McCreesh