| 1 |
On Sunday 06 December 2009 11:48:13 Ulrich Mueller wrote: |
| 2 |
> > Depending on the exact wording and exceptions this can be |
| 3 |
> > made equivalent to 5.3 below. |
| 4 |
> |
| 5 |
> Right, that's the intention of it. |
| 6 |
|
| 7 |
The intention is to make the spec for a new EAPI unnecessarily complex, just |
| 8 |
to avoid changing an existing implementation? |
| 9 |
|
| 10 |
> We should also consider including this in EAPI 0 retroactively |
| 11 |
|
| 12 |
Doing things like that defeats the purpose of EAPI. |
| 13 |
|
| 14 |
> 2007-07-28 Portage 2.1.3 is released, preserving mtimes when |
| 15 |
> merging (if release candidates are counted, then the |
| 16 |
> date is even earlier [2]). |
| 17 |
|
| 18 |
This was long after EAPI was invented, so it should have gone in with an EAPI |
| 19 |
bump. |
| 20 |
|
| 21 |
> 2008-05-08 PMS allows that file modification times are discarded. [3] |
| 22 |
|
| 23 |
That commit changed the wording from "Other file attributes may be discarded" |
| 24 |
to "Other file attributes, including modification time, may be discarded". |
| 25 |
Modification time was already included in the phrase "other file attributes", |
| 26 |
all the change did was to clarify it. |
| 27 |
|
| 28 |
Also note that just because something isn't mentioned in PMS doesn't mean it's |
| 29 |
OK to go off and do whatever you feel like, without regard for compatibility, |
| 30 |
especially if it's a long-standing, well-defined behaviour like "reset mtimes |
| 31 |
to the current time". People are expected to use common-sense when reading |
| 32 |
it (since we don't have enough man-power to make it completely airtight), not |
| 33 |
deliberately misinterpret it to support their own agenda (last part not |
| 34 |
directed at you, but that sort of behaviour has happened in the past). |
Archives