| 1 |
Jakub Moc wrote: |
| 2 |
> Erm, how exactly will you find out that you need to recompile that package |
| 3 |
> after such extensive build? You'll spend a couple of hours debugging when |
| 4 |
> your server app stops working? Yay! :P |
| 5 |
|
| 6 |
I had assumed that in such a case the ebuild would output a |
| 7 |
scary-looking ewarn that notified the user of such a problem. |
| 8 |
|
| 9 |
> Oh please, stop making up artificial policies doing no good to users just to |
| 10 |
> hack around lacking features in portage. |
| 11 |
|
| 12 |
Was I so impolite that you felt the need to be rude in turn? If so, I |
| 13 |
certainly apologize, as it was not my intention. |
| 14 |
|
| 15 |
I don't believe that I made up this policy, although it's been around as |
| 16 |
an unofficial policy for so long that I couldn't really say one way or |
| 17 |
the other. In any event, I certainly agree that fixing portage would be |
| 18 |
preferable to policies that work around portage's warts. On the other |
| 19 |
hand, until those warts get fixed it seems useful to have a set of "best |
| 20 |
practices" in the meantime. I'm arguing that sudden, difficult to |
| 21 |
predict package build breakages are a bigger sin than having a package |
| 22 |
build deterministic functionality that may be unexpected by the user. |
| 23 |
You (I think) believe the opposite. Fair enough. |
| 24 |
|
| 25 |
-g2boojum- |
Archives