| 1 |
On Thu, 1 Oct 2009 16:49:43 +0200 |
| 2 |
Ulrich Mueller <ulm@g.o> wrote: |
| 3 |
> > Why go with an inferior solution? Why not go with a solution that |
| 4 |
> > requires the package manager to fix broken mtimes? |
| 5 |
> |
| 6 |
> Because it would be non-zero implementation cost for Portage, so |
| 7 |
> probably out of question for EAPI 3. |
| 8 |
|
| 9 |
It's cheap, and it's doing it the right way. If we were to design the |
| 10 |
feature up-front rather than going with whatever Portage does, we'd go |
| 11 |
with mtime fixing. |
| 12 |
|
| 13 |
> And it's not at all clear if the solution is inferior. Since half a |
| 14 |
> year, nobody cared to answer the question of comment 25 of mentioned |
| 15 |
> bug. |
| 16 |
|
| 17 |
Because comment 25 is entirely missing the point. The objection is not |
| 18 |
to preservation. The objection is to pure preservation with no handling |
| 19 |
for dodgy mtimes. |
| 20 |
|
| 21 |
> > Also, what are the rules regarding this and things like stripping |
| 22 |
> > and other fixes and changes that the package manager performs upon |
| 23 |
> > files before merging them? |
| 24 |
> |
| 25 |
> This is outside the scope of this proposal, and (at least for now) I'm |
| 26 |
> not going to work anything out. |
| 27 |
|
| 28 |
It's not. It's a necessary part of the proposal. You need to define the |
| 29 |
behaviour here, since if you don't, we're back to ebuilds relying upon |
| 30 |
undefined behaviour. |
| 31 |
|
| 32 |
What you're effectively saying by ignoring this is "mtimes must be |
| 33 |
preserved, except when they're not". That isn't good enough, since it |
| 34 |
would be entirely legal for a package manager to not do any |
| 35 |
preservation at all then. Alternatively, you're saying "mtimes must |
| 36 |
always be preserved", in which case Portage isn't compliant. This isn't |
| 37 |
something you can just ignore. |
| 38 |
|
| 39 |
-- |
| 40 |
Ciaran McCreesh |
Archives