| 1 |
Alan McKinnon <alan.mckinnon <at> gmail.com> writes: |
| 2 |
|
| 3 |
|
| 4 |
>> And it was also because of a cross-compiler. When I looked at how much |
| 5 |
>> extra work this type fragmentation causes, and how little (or any!) |
| 6 |
>> advantage it gives makes one wonder about the designers sanity ... |
| 7 |
|
| 8 |
I've run across this several times already. For now I have avoided the |
| 9 |
dir expansion, as I find one (larger) file easier to parse. Often I less the |
| 10 |
one file to see what is in there and delete things manually. |
| 11 |
It would seem like when you delete (-C) a package it would check all of |
| 12 |
/etc/portage for entries to remove, but I do not think that happens. |
| 13 |
Still, now that we're all moving to git everywhere (on your system) |
| 14 |
I suspect having separate files is better/easier for those devs and hackers |
| 15 |
amongst us. |
| 16 |
|
| 17 |
|
| 18 |
> What ought to have happened, and the convention had long existed when |
| 19 |
> this scheme for portage was thought up, is to call the directory |
| 20 |
> /etc/portage/package.mask.d/ |
| 21 |
> then you could easily have a main file and as many subsidiary files as |
| 22 |
> you need/want. Just like how every other package seems to do it. |
| 23 |
|
| 24 |
Yep. Brilliant and simple. |
| 25 |
|
| 26 |
File a bug:: feature request. |
| 27 |
|
| 28 |
Why not make the request. We already support /etc/make.conf and |
| 29 |
/etc/portage/make.conf so masking can occur in (2) dirs to ease the |
| 30 |
migration to a more sensible nomenclature and tree structure.... |
| 31 |
|
| 32 |
James |
Archives