| 1 |
On Sun, Jan 19, 2014 at 5:47 AM, Alexander Berntsen |
| 2 |
<alexander@××××××.net> wrote: |
| 3 |
> On 19/01/14 11:32, Pacho Ramos wrote: |
| 4 |
>> Then, I guess "-ap" would be the equivalent of --autounmask=n and |
| 5 |
>> should behave in the same way, right? In that case, no problem |
| 6 |
>> (even if I think we should document this since using --ask |
| 7 |
>> --pretend at the same time doesn't look so intuitive to me :( ) |
| 8 |
> Since --ask implies --autounmask, the following are all the same for |
| 9 |
> autounmask-purposes: |
| 10 |
> |
| 11 |
> emerge --pretend --ask foo |
| 12 |
> emerge --pretend --autounmask foo |
| 13 |
> |
| 14 |
> As for "emerge --autounmask=n foo", This will actually spit out the |
| 15 |
> suggestions, just not ask to write them. |
| 16 |
> |
| 17 |
> While playing with this, I discovered a possible misbehaviour though. |
| 18 |
> With "emerge --ask --autounmask=n", --ask takes precedence to |
| 19 |
> - --autounmask=n. Maybe it shouldn't. But this can always be changed. |
| 20 |
|
| 21 |
Please give me a way to shut off autounmask entirely no mater what |
| 22 |
other options I pass to emerge. Tying it to --ask with no way to |
| 23 |
disable it is not acceptable. |
| 24 |
|
| 25 |
Generating the unmask entries can cause quite a performance hit, and |
| 26 |
often causes portage to come up with nonsensical solutions when an |
| 27 |
error message would be much more helpful. |
Archives