>>>>> On Thu, 26 Nov 2009, Ciaran McCreesh wrote:

>> Real examples would be issues like bugs 83877 [1] or 263387 [2].
>> Nothing that could be easily dismissed or worked around. Both issues
>> are fixed with Portage since a long time.

> Yes, those are examples of packages relying upon something that is
> undefined behaviour,

That was the reason why I filed bug 264130, in the first place. ;-)

> and that behaves differently depending upon the Portage version you
> use.

Fact is that all versions of Portage in the tree get it right for both
packages, but Paludis fails for them.

> objfile, whose mtime should be a bit later than srctime's, gets
> installed with its mtime corrupted to be slightly less than it
> should be, and less than srctime's, because it is installed the slow
> way.

The major usage cases where mtimes play a role (*.py vs *.pyc, *.lisp
vs *.fasl, and *.el vs *.elc) install source and object files in the
same directory. So why would the PM use different methods for
installing them?

> A program checks that objfile's mtime is greater than or equal to
> srcfile's mtime. That check will fail, and reinstalls will randomly
> fix and break it depending upon which way the corruption goes.

Again, you don't come up with a concrete example where such breakage
would occur.

I'm starting to get tired of this whole discussion. Maybe we should
just follow Calchan's suggestion and do nothing. Portage works, after
all.

Ulrich

Reply via email to