On 08/13/18 13:17, Nikos Chantziaras wrote: > On 13/08/18 17:31, james wrote: >> Hello, >> >> Q1} In my attempts to minimize flag settings, why do I need the flag >> "icu" ? >> >> + - icu�� Enable ICU (Internationalization Components for Unicode) >> ������� support, using dev-libs/icu > > Depends on the software. If my software uses ICU for Unicode-related > stuff, I might provide a way to disable Unicode support, or have a > half-assed custom implementation that doesn't need ICU but is slower > and/or doesn't support all Unicode features.
yep, no such replacement (yet) but up for suggestions, if anything already exist. What you state is exactly the point, I'm a bit shy on system wide removal of this flag, without a much deeper understanding of it's potential effects, which may be catastrophic. I'm not sure how to dissect ICU (dev-libs/icu) and the 'icu' flag. What the heck oare 'international components' ? I get the universal ascii character set, that fine. but is that all it is or is there more baggage strictly not necessary ? What is Unicode? Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language. I have no need to support chineese or any other language other that english (AM or EN). Does UTF-8 get rid of significant bloat? Currently I have:: # locale -a C POSIX en_US en_US.iso88591 en_US.utf8 Perhaps I've read 'too much' and should just run with icu as a global flag? > > The default USE flags are supposed to reflect the recommended way to > build the various software packages, either as recommended by upstream > or determined by the package maintainers. > > Unfortunately, most packages don't document their USE flags in their > metadata, so the user has to go hunting for an explanation for each > package. But even if each package explained what a USE flag actually > means for that package, it would be borderline impossible to go through > each every package of a system to verify whether you lose something > important or not when you change a USE flag. Agreed with all you state. I do not intend to do this, except for those flags set in the relevant @system (package) listing. Everything else can be part of a 'framework' that is additive/removable on the HPC cluster, dynamically. Since these extra frameworks are already often 'huge' it matters only that all of those packages in a framework, work as needed. But optimizing the engine underneath, across the cluster, it's very important to have things minimized. And since the clusters are 'loosely coupled' many different processors and architectures can participate. The smaller the critical package list is and the subsequent flags, the easier the cluster will be to boot/run/optimize/maintain. Thus the requirement for the @system package listings with flags per many arches are tremendously beneficial to my research and testing. Yes, I do need to robustly examine not only the @system package list, but each and every flag. I pretty much agree with your sentiments, even get a bit of a chuckle as one of the few that has been 86'd off both gentoo-user and gentoo-dev, but wanting to stay focused on the needs of my HPC semantics. James
