| 1 |
On Wed, Aug 13, 2014 at 1:59 PM, Duncan <1i5t5.duncan@×××.net> wrote: |
| 2 |
> Alexander Berntsen posted on Wed, 13 Aug 2014 18:56:28 +0200 as excerpted: |
| 3 |
>> |
| 4 |
>> emerge foo # this will do what --autounmask does today |
| 5 |
>> emerge foo --autounmask # this will do what --autounmask-write does |
| 6 |
>> emerge foo -a # this will do what --ask --autounmask-write does |
| 7 |
>> emerge foo --autounmask=n # this will do what --autounmask=n does |
| 8 |
>> |
| 9 |
>> The problem here is that there is no way to do e.g. emerge foo --ask, |
| 10 |
>> and get suggestions any longer. You can either have it prompt to write |
| 11 |
>> stuff, or you can have it not do anything -- but you can't explicitly |
| 12 |
>> have it suggest stuff without prompting to write. This is bad design. |
| 13 |
>> |
| 14 |
Is there really any situation where the user would benefit from not |
| 15 |
having the suggestions? That's sort of rhetorical because it's on by |
| 16 |
default, but the point is more that Portage already takes a rather |
| 17 |
proactive stance with regard to informing the user about the details |
| 18 |
of slot and version conflicts; what's a few more lines? (And if that |
| 19 |
IS, indeed, a problem, there's always --quiet.) |
| 20 |
|
| 21 |
Regardless of that, writing keywords as a side-effect of --ask is not |
| 22 |
a good path. My personal suggestion would instead be that |
| 23 |
--autounmask only do exactly what it says: automatically resolve |
| 24 |
minimum keywords needed to merge the depgraph and put them where they |
| 25 |
need to be. When used in conjunction with --ask, it would then tell |
| 26 |
you "These atoms will be appended to package.keywords" or whatever |
| 27 |
file it chooses. Unfortunately historical baggage may prevent that, |
| 28 |
but it's a nice thought. |
| 29 |
|
| 30 |
> * I don't want portage writing mask/use changes on its own under any |
| 31 |
> circumstances, as I use directories and have my own idea of what files I |
| 32 |
> want stuff in. |
| 33 |
> |
| 34 |
I have this same issue as I give every category its own file. Can we |
| 35 |
generalise this in such a way that finer-grained control over write |
| 36 |
location could be added? (Off the top of my head, I'm imagining |
| 37 |
passing the atom through something like a FILE_REGEX or maybe an |
| 38 |
optional script parameter, and the output is the filename within |
| 39 |
package.keywords/) |
| 40 |
|
| 41 |
-Wyatt |
Archives