On 06/11/2013 14:54, Martin Vaeth wrote: > Marc Joliet <mar...@gmx.de> wrote: >> >> One of those questions stands out to me right now: the one on understandable >> error messages. As some recent posts to this ML demonstrate, it seems to >> be one area where portage is visibly falling (staying?) behind right now. >> They remind me of the type of error message gcc/g++ spit out, actually. > > In both cases, it is technically very cumbersome to get good > error messages. In fact, it would need alone more work in programming > than to do the actual job (and it would slow down execution time > drastically even if no errors arise). > > Concerning portage, the situation is apparently this > (I am guessing this only from the outputs which are posted): > > When portage detects that it cannot resolve something after > backtracking, it dies. Then all non-resolved conflicts are > spit out - often these are some that *could* be resolved. > So instead of dying, portage would need to try to continue > to resolve anyway partially as far as it could and only then > die. This would mean that branches cannot be cut, so the runtime > would probably increase tremendously. Moreover, the result might > be even more confusing if there is some strange branch in which > slightly more resolving is possible.
That by itself is good info. The conflict that portage couldn't resolve, is it the first one in the printed list, or the last? This helps tell us what bits we can ignore at least until the next emerge run -- Alan McKinnon alan.mckin...@gmail.com
