| 1 |
On Sat, May 16, 2015 at 7:50 AM, Neil Bothwick <neil@××××××××××.uk> wrote: |
| 2 |
> On Sat, 16 May 2015 07:16:58 -0400, Rich Freeman wrote: |
| 3 |
>> |
| 4 |
>> Well, it can be a lot more than two screens of text. I have 1300 |
| 5 |
>> lines of package.use, almost all of it for abi_x86_32. I suspect that |
| 6 |
>> this the result of stuff like steam, wine, android-sdk-update-manager, |
| 7 |
>> and eternal-lands - all packages that involve graphics libraries and |
| 8 |
>> toolkits with huge dependency trees. |
| 9 |
> |
| 10 |
> Does that include the several lines of comments, often repeated, that |
| 11 |
> portage includes in the auto-unmask output? I just checked two systems |
| 12 |
> for abi_x86_32 and got around 130 lines in one and 220 in the other. |
| 13 |
|
| 14 |
Yes, it does. The number of actual configuration lines is much |
| 15 |
smaller of course - probably 1/5th of the total. |
| 16 |
|
| 17 |
My point wasn't so much that this was an inordinate number of 32-bit |
| 18 |
packages, given my list of installed packages. It was more about the |
| 19 |
fact that on a system that I'm trying to keep fairly minimal other |
| 20 |
than my explicit preferences I end up with a huge config file that |
| 21 |
tends to mix my preferences with a lot of stuff that exists solely to |
| 22 |
satisfy the depgraph. It would be like sticking every package I |
| 23 |
install in my world set. |
| 24 |
|
| 25 |
There are some ways around this which I'll probably get around to on a |
| 26 |
rainy day: |
| 27 |
|
| 28 |
1. Take better advantage of the fact that package.use can be a |
| 29 |
directory and have several files. The 32-bit flags would go in their |
| 30 |
own file. Autounmask goes in a separate file with a z at the start of |
| 31 |
the name and the intent is that lines in this file get moved to the |
| 32 |
appropriate files. Then from time to time the 32-bit flags can be |
| 33 |
deleted and re-created to keep them minimal as installed packages |
| 34 |
change. |
| 35 |
|
| 36 |
2. What I'd really like to get to is a point where all my systems are |
| 37 |
defined by ansible configs or the like. I've already started |
| 38 |
container-izing many of my services to cut down on interactions - this |
| 39 |
way when I do random package updates I'm not dealing with mysql |
| 40 |
breaking or apache or whatever. However, this increases the amount of |
| 41 |
updating I have to do, and I'd like to bring that back down using a |
| 42 |
tool like ansible. |
| 43 |
|
| 44 |
-- |
| 45 |
Rich |
Archives