On Thu, 1 Oct 2009 16:49:43 +0200
Ulrich Mueller <ulm@g.o> wrote:
> > Why go with an inferior solution? Why not go with a solution that
> > requires the package manager to fix broken mtimes?
> 
> Because it would be non-zero implementation cost for Portage, so
> probably out of question for EAPI 3.

It's cheap, and it's doing it the right way. If we were to design the
feature up-front rather than going with whatever Portage does, we'd go
with mtime fixing.

> And it's not at all clear if the solution is inferior. Since half a
> year, nobody cared to answer the question of comment 25 of mentioned
> bug.

Because comment 25 is entirely missing the point. The objection is not
to preservation. The objection is to pure preservation with no handling
for dodgy mtimes.

> > Also, what are the rules regarding this and things like stripping
> > and other fixes and changes that the package manager performs upon
> > files before merging them?
> 
> This is outside the scope of this proposal, and (at least for now) I'm
> not going to work anything out.

It's not. It's a necessary part of the proposal. You need to define the
behaviour here, since if you don't, we're back to ebuilds relying upon
undefined behaviour.

What you're effectively saying by ignoring this is "mtimes must be
preserved, except when they're not". That isn't good enough, since it
would be entirely legal for a package manager to not do any
preservation at all then. Alternatively, you're saying "mtimes must
always be preserved", in which case Portage isn't compliant. This isn't
something you can just ignore.

-- 
Ciaran McCreesh