| 1 |
>>>>> On Thu, 26 Nov 2009, Ciaran McCreesh wrote: |
| 2 |
|
| 3 |
>> Real examples would be issues like bugs 83877 [1] or 263387 [2]. |
| 4 |
>> Nothing that could be easily dismissed or worked around. Both issues |
| 5 |
>> are fixed with Portage since a long time. |
| 6 |
|
| 7 |
> Yes, those are examples of packages relying upon something that is |
| 8 |
> undefined behaviour, |
| 9 |
|
| 10 |
That was the reason why I filed bug 264130, in the first place. ;-) |
| 11 |
|
| 12 |
> and that behaves differently depending upon the Portage version you |
| 13 |
> use. |
| 14 |
|
| 15 |
Fact is that all versions of Portage in the tree get it right for both |
| 16 |
packages, but Paludis fails for them. |
| 17 |
|
| 18 |
> objfile, whose mtime should be a bit later than srctime's, gets |
| 19 |
> installed with its mtime corrupted to be slightly less than it |
| 20 |
> should be, and less than srctime's, because it is installed the slow |
| 21 |
> way. |
| 22 |
|
| 23 |
The major usage cases where mtimes play a role (*.py vs *.pyc, *.lisp |
| 24 |
vs *.fasl, and *.el vs *.elc) install source and object files in the |
| 25 |
same directory. So why would the PM use different methods for |
| 26 |
installing them? |
| 27 |
|
| 28 |
> A program checks that objfile's mtime is greater than or equal to |
| 29 |
> srcfile's mtime. That check will fail, and reinstalls will randomly |
| 30 |
> fix and break it depending upon which way the corruption goes. |
| 31 |
|
| 32 |
Again, you don't come up with a concrete example where such breakage |
| 33 |
would occur. |
| 34 |
|
| 35 |
I'm starting to get tired of this whole discussion. Maybe we should |
| 36 |
just follow Calchan's suggestion and do nothing. Portage works, after |
| 37 |
all. |
| 38 |
|
| 39 |
Ulrich |
Archives