| 1 |
3.3.2006, 23:32:36, Grant Goodyear wrote: |
| 2 |
|
| 3 |
> Jakub Moc wrote: |
| 4 |
>> Erm, how exactly will you find out that you need to recompile that package |
| 5 |
>> after such extensive build? You'll spend a couple of hours debugging when |
| 6 |
>> your server app stops working? Yay! :P |
| 7 |
|
| 8 |
> I had assumed that in such a case the ebuild would output a |
| 9 |
> scary-looking ewarn that notified the user of such a problem. |
| 10 |
|
| 11 |
The whole argument here is that bailing out with conflicting use flags |
| 12 |
breaks some extensive compiles. So you suppose users will be sitting in |
| 13 |
front of their monitor and stare on the screen waiting for a scary warning? |
| 14 |
No, they won't. And even if they were, how exactly is that warning better |
| 15 |
than bailing out and asking them to change the use flags? |
| 16 |
|
| 17 |
The only thing that can happen here is that users will get unexpected |
| 18 |
results and will be debugging their broken apps once that extensive compile |
| 19 |
that must not be interrupted under any circumstances is finished. |
| 20 |
|
| 21 |
>> Oh please, stop making up artificial policies doing no good to users just to |
| 22 |
>> hack around lacking features in portage. |
| 23 |
|
| 24 |
> Was I so impolite that you felt the need to be rude in turn? If so, I |
| 25 |
> certainly apologize, as it was not my intention. |
| 26 |
|
| 27 |
No, sorry. That comment was aimed generally at whomever is making up such |
| 28 |
policies. I'm really getting tired of this debate. Lets drop the damned |
| 29 |
paragraph that has been added recently and lets do some more important job. |
| 30 |
This simply cannot be fixed now in a reasonable way that would improve user |
| 31 |
experience, so why don't we focus on something that is doable? |
| 32 |
|
| 33 |
> I don't believe that I made up this policy, although it's been around as |
| 34 |
> an unofficial policy for so long that I couldn't really say one way or |
| 35 |
> the other. In any event, I certainly agree that fixing portage would be |
| 36 |
> preferable to policies that work around portage's warts. On the other |
| 37 |
> hand, until those warts get fixed it seems useful to have a set of "best |
| 38 |
> practices" in the meantime. I'm arguing that sudden, difficult to |
| 39 |
> predict package build breakages are a bigger sin than having a package |
| 40 |
> build deterministic functionality that may be unexpected by the user. |
| 41 |
> You (I think) believe the opposite. Fair enough. |
| 42 |
|
| 43 |
Well, selecting features randomly is not what I believe could be a "best |
| 44 |
practice". |
| 45 |
|
| 46 |
-- |
| 47 |
|
| 48 |
jakub |
Archives