| 1 |
On 14/08/17 02:55, Duncan wrote: |
| 2 |
> M. J. Everitt posted on Mon, 14 Aug 2017 00:37:45 +0100 as excerpted: |
| 3 |
> |
| 4 |
>> My use-case consists of the scenario where I do not *ever* wish Portage |
| 5 |
>> to modify my /etc/portage/package.<anything> files, preferring to do |
| 6 |
>> this myself manually with a personal naming scheme which defines which |
| 7 |
>> target packages are causing dependency issues. This would be a rather |
| 8 |
>> cool feature-request for portage itself, but I don't see it being |
| 9 |
>> implemented Any Time Soon™. |
| 10 |
>> |
| 11 |
>> This was why I have enforced --autounmask=n in my EMERGE_DEFAULT_OPTS as |
| 12 |
>> often it causes more harm than good if 'random' entries in |
| 13 |
>> /etc/portage/<anything> starts to cause later issues with updated |
| 14 |
>> library packages (read Perl, Python and any other dev-lang nasties |
| 15 |
>> here). |
| 16 |
> FWIW, my use-case is similar. I don't /ever/ want portage doing |
| 17 |
> automated portage-config changes, because I have my own organization, and |
| 18 |
> I comment every change so I know when, what, why, and there's no way an |
| 19 |
> automated tool (well, perhaps some IBM or Google AI, but...) is going to |
| 20 |
> be able to get that even close to correct enough for my satisfaction.[1] |
| 21 |
> |
| 22 |
> However, I've found the /suggestions/ portage makes with auto-unmask |
| 23 |
> useful, as long as they remain just that, *suggestions*, that I can |
| 24 |
> decide on and write up as I wish. |
| 25 |
> |
| 26 |
> And --autounmask-write=n gets me the best of both worlds. Portage |
| 27 |
> doesn't write changes but still suggests them. |
| 28 |
> |
| 29 |
> If you've not tried it, I suggest you do. Works great for me! =:^) |
| 30 |
> |
| 31 |
> --- |
| 32 |
> [1] Besides, doing it manually means I remember the details I did /not/ |
| 33 |
> put down much more readily, once prompted by the ones I did. Even if an |
| 34 |
> automated version could do it it'd need to write paragraphs in ordered to |
| 35 |
> allow me to make sense of it a year or whatever later, compared to my |
| 36 |
> single line when done manually. |
| 37 |
> |
| 38 |
Interesting .. I'm sure I shied away from that option for some reason |
| 39 |
... wonder if zmedico can shed some light on the difference between the |
| 40 |
new options and the old, apart from some added flexibility ... |
Archives