3.3.2006, 23:32:36, Grant Goodyear wrote:

> Jakub Moc wrote:
>> Erm, how exactly will you find out that you need to recompile that package
>> after such extensive build? You'll spend a couple of hours debugging when
>> your server app stops working? Yay! :P

> I had assumed that in such a case the ebuild would output a
> scary-looking ewarn that notified the user of such a problem.

The whole argument here is that bailing out with conflicting use flags
breaks some extensive compiles. So you suppose users will be sitting in
front of their monitor and stare on the screen waiting for a scary warning?
No, they won't. And even if they were, how exactly is that warning better
than bailing out and asking them to change the use flags?

The only thing that can happen here is that users will get unexpected
results and will be debugging their broken apps once that extensive compile
that must not be interrupted under any circumstances is finished.

>> Oh please, stop making up artificial policies doing no good to users just to
>> hack around lacking features in portage.

> Was I so impolite that you felt the need to be rude in turn?  If so, I
> certainly apologize, as it was not my intention.

No, sorry. That comment was aimed generally at whomever is making up such
policies. I'm really getting tired of this debate. Lets drop the damned
paragraph that has been added recently and lets do some more important job.
This simply cannot be fixed now in a reasonable way that would improve user
experience, so why don't we focus on something that is doable?

> I don't believe that I made up this policy, although it's been around as
> an unofficial policy for so long that I couldn't really say one way or
> the other.  In any event, I certainly agree that fixing portage would be
> preferable to policies that work around portage's warts.  On the other
> hand, until those warts get fixed it seems useful to have a set of "best
> practices" in the meantime.  I'm arguing that sudden, difficult to
> predict package build breakages are a bigger sin than having a package
> build deterministic functionality that may be unexpected by the user.
> You (I think) believe the opposite.  Fair enough.

Well, selecting features randomly is not what I believe could be a "best
practice".

-- 

jakub

Attachment: pgplAlVlbQEm0.pgp
Description: PGP signature

Reply via email to