| 1 |
-- John Robinson <strider@××××××.net> spake thusly: |
| 2 |
|
| 3 |
> Q: Shouldn't we list the two packages for an interactive choice when |
| 4 |
> two or more are available? |
| 5 |
> |
| 6 |
> A: Interactive choice is against the design of emerge. We need to be |
| 7 |
> able to use it more easily in scripts than that would allow. The best |
| 8 |
> we can do is to generate an error with that information and let the |
| 9 |
> user pick and re-run emerge. |
| 10 |
|
| 11 |
<snip> |
| 12 |
|
| 13 |
> Is there a reason why emerge couldn't have a command line switch to |
| 14 |
> cause it to deviate from its current behavior and give the user an |
| 15 |
> interactive choice? I gather that the error-choice option is currently |
| 16 |
> in the bugs db waiting for implementation, but a lot of users have |
| 17 |
> seemed to like the idea of the interactive option, which I think a |
| 18 |
> command line switch could integrate well. Is there a reason why this |
| 19 |
> should be avoided? |
| 20 |
|
| 21 |
Another option would be to allow emerge to be interactive when run from |
| 22 |
a shell and to throw errors or make assumptions at other times. This |
| 23 |
would be similar to the way ls shows colored output when run from a |
| 24 |
shell, but not when piped to less or run from a script. |
| 25 |
|
| 26 |
If a switch were used, I would suggest defaulting to interactive |
| 27 |
behavior with a switch to disable it. |
| 28 |
|
| 29 |
|
| 30 |
-- |
| 31 |
gentoo-dev@g.o mailing list |
Archives