| 1 |
On 08/13/18 13:17, Nikos Chantziaras wrote: |
| 2 |
> On 13/08/18 17:31, james wrote: |
| 3 |
>> Hello, |
| 4 |
>> |
| 5 |
>> Q1} In my attempts to minimize flag settings, why do I need the flag |
| 6 |
>> "icu" ? |
| 7 |
>> |
| 8 |
>> + - icu�� Enable ICU (Internationalization Components for Unicode) |
| 9 |
>> ������� support, using dev-libs/icu |
| 10 |
> |
| 11 |
> Depends on the software. If my software uses ICU for Unicode-related |
| 12 |
> stuff, I might provide a way to disable Unicode support, or have a |
| 13 |
> half-assed custom implementation that doesn't need ICU but is slower |
| 14 |
> and/or doesn't support all Unicode features. |
| 15 |
|
| 16 |
yep, no such replacement (yet) but up for suggestions, if anything |
| 17 |
already exist. What you state is exactly the point, I'm a bit shy |
| 18 |
on system wide removal of this flag, without a much deeper understanding |
| 19 |
of it's potential effects, which may be catastrophic. I'm not sure how |
| 20 |
to dissect ICU (dev-libs/icu) and the 'icu' flag. What the heck oare |
| 21 |
'international components' ? |
| 22 |
|
| 23 |
I get the universal ascii character set, that fine. but is that all it |
| 24 |
is or is there more baggage strictly not necessary ? |
| 25 |
|
| 26 |
What is Unicode? |
| 27 |
Unicode provides a unique number for every character, no matter what the |
| 28 |
platform, no matter what the program, no matter what the language. I |
| 29 |
have no need to support chineese or any other language other that |
| 30 |
english (AM or EN). Does UTF-8 get rid of significant bloat? |
| 31 |
|
| 32 |
Currently I have:: |
| 33 |
|
| 34 |
# locale -a |
| 35 |
C |
| 36 |
POSIX |
| 37 |
en_US |
| 38 |
en_US.iso88591 |
| 39 |
en_US.utf8 |
| 40 |
|
| 41 |
|
| 42 |
Perhaps I've read 'too much' and should just run with icu as a global flag? |
| 43 |
|
| 44 |
|
| 45 |
> |
| 46 |
> The default USE flags are supposed to reflect the recommended way to |
| 47 |
> build the various software packages, either as recommended by upstream |
| 48 |
> or determined by the package maintainers. |
| 49 |
> |
| 50 |
> Unfortunately, most packages don't document their USE flags in their |
| 51 |
> metadata, so the user has to go hunting for an explanation for each |
| 52 |
> package. But even if each package explained what a USE flag actually |
| 53 |
> means for that package, it would be borderline impossible to go through |
| 54 |
> each every package of a system to verify whether you lose something |
| 55 |
> important or not when you change a USE flag. |
| 56 |
|
| 57 |
|
| 58 |
Agreed with all you state. I do not intend to do this, except for those |
| 59 |
flags set in the relevant @system (package) listing. |
| 60 |
|
| 61 |
Everything else can be part of a 'framework' that is additive/removable |
| 62 |
on the HPC cluster, dynamically. Since these extra frameworks are |
| 63 |
already often 'huge' it matters only that all of those packages in a |
| 64 |
framework, work as needed. |
| 65 |
|
| 66 |
|
| 67 |
But optimizing the engine underneath, across the cluster, it's very |
| 68 |
important to have things minimized. And since the clusters are |
| 69 |
'loosely coupled' many different processors and architectures can |
| 70 |
participate. The smaller the critical package list is and the subsequent |
| 71 |
flags, the easier the cluster will be to boot/run/optimize/maintain. |
| 72 |
Thus the requirement for the @system package listings with flags per |
| 73 |
many arches are tremendously beneficial to my research and testing. |
| 74 |
Yes, I do need to robustly examine not only the @system package list, |
| 75 |
but each and every flag. |
| 76 |
|
| 77 |
|
| 78 |
I pretty much agree with your sentiments, even get a bit of a chuckle as |
| 79 |
one of the few that has been 86'd off both gentoo-user and gentoo-dev, |
| 80 |
but wanting to stay focused on the needs of my HPC semantics. |
| 81 |
|
| 82 |
|
| 83 |
James |
Archives