It is very anoying that the use flag nls is used to activate the mbstring-extension in dev-lang/php. On my server I switched off nls completly since I do not need it in the environment. After upgrading from dev-php/php to dev-lang/php I realized in my application and in the php-binaries, that no mb_* function existed anymore. I spent quite some time to find the reason for this behavior. I had to manually check the php5_1-sapi.eclass to see, that several UTF-8 related things are dependant on the nls use flag, that is documented in use.desc as nls - Adds Native Language Support (using gettext - GNU locale utilities) This has obviously no (direct) relationship with multibyte character handling. Please add a separate useflag for multibyte related extensions and options of php.
switching it to USE=unicode should be fine
Done. "nls" USE flag --> enables gettext extension as per use.desc description "unicode" USE flag --> enables mbstring extension and other Unicode/UTF8 related things as per use.desc description @vapier: could you please check the Horde ebuild, I see that it checks for "nls", which previously was gettext & mbstring, now it's only gettext, so please check if the Horde ebuilds needs some kind of update to check for unicode too, or for unicode only, or whatever. ;) Thanks! Please close the bug once you've checked that. Best regards, CHTEKK.
(In reply to comment #2) > Done. > "nls" USE flag --> enables gettext extension as per use.desc description > "unicode" USE flag --> enables mbstring extension and other Unicode/UTF8 > related things as per use.desc description > Unfortunatelly it's a totally false concept to expect, that only those people, who install php scripts using mbstring functions will have their unicode USE flag enabled. I have a non-unicode box, on which the last php update made squirrelmail unusable because of this damned eclass change. I have nls enabled, which kept mbstring enabled until the point the dependecy was moved to unicode. This is the second time in a month I have to tweak an eclass to get back a functionality screwed up by an update without even a m*f* notice. Because of utf8 related (mysql) eclass changes. I'll open a bug to revert this change, cos I suspect that all non-unicode users dealing with php scripts using mbstring functions are now cursed. The best would be to have a separate USE flag for mbstring, or have it just enabled by default in eclass. m*f* Please stop it somehow. Regards, Dw.
No. Not another use flag, enough really. And - there's no functionality "screwed up", calm down please.
*** Bug 132735 has been marked as a duplicate of this bug. ***
I fail to see the problem per se... I agree a warning was missing for this change, sorry about that. But wrt the change itself, it's totally logical. The gettext extension is enabled by the "nls" USE flag, because the nls USE flag is there to enable gettext support, read the description. The mbstring extension is enabled by the "unicode" USE flag, as it's the (for now) only extension in PHP dealing with unicode and other multibyte charsets, so it looks quite alright to me. Having it enabled by default is not an option, as it's an _optional_ extension, so an USE flag to turn it on/off is needed. Conclusion: we won't change it another time, screwing over even more users if we'd do that change, since as it's now, it looks quite logical and ok. Use /etc/portage/package.use to set per-package flags if you don't want unicode enabled on all packages, anyway. Best regards, CHTEKK. @vapier: please check wrt Horde and close then, tnx!
(In reply to comment #4) > No. Not another use flag, enough really. And - there's no functionality > "screwed up", calm down please. > Not screwed, but at least stopped working as they did before. Not another but it should not be unicode or utf-8 either. It's obvious, that not just those people need mbstring who have "unicode" enabled. I think it would be much more complicated for users to include a warning, that if they don't have "unicode" enabled and want to use mbstring extension, it must be enabled solely to php in package.use. I won't think a regular user would be aware of this. Regards, Dwokfur
(In reply to comment #6) > I fail to see the problem per se... I don't want to harass any developers, and thank you for all of your efforts. Just have a look at on squirrelmail for e.g. All users who upgraded to the latest stable php, and running a non-unicode box will experince a service failure. Squirrelmail is quite popular IMHO, and it is my favourite webmail suite. Fortunately I've learned previously (mysql) where to look for these kind of problems, so it took half a second to find the source of this phenomenon (after update). But I suspect a lot of stucked users. I don't like the idea to require users to tweak package.use for a must-have functionality. It sounds something like punishing those who decide against unicode (there where some practical causes in my case). I agree, that mbstring is a unicode related extension, but all users need it, who run php scripts utilizing this extension regardless of what encoding/locale is activated. Please find some other solution. Question is: how many people out there having unicode enabled and nls disabled, and how many bastards having the opposite? I suspect, that the latter bunch is probably not a small group. Regards, Dwokfur
(In reply to comment #8) > I agree, that mbstring is a unicode related extension, but all users need it, > who run php scripts utilizing this extension regardless of what encoding/locale > is activated. Then file a bug about squirrelmail, it should check for the needed php use flag.
(In reply to comment #9) > (In reply to comment #8) > > I agree, that mbstring is a unicode related extension, but all users need it, > > who run php scripts utilizing this extension regardless of what encoding/locale > > is activated. > > Then file a bug about squirrelmail, it should check for the needed php use > flag. > Forget it, it's not related to squirrelmail. Unicode is not a php USE flag. It's a system-wide use flag, which indicates if it's a unicode enabled system or not. Not just those systems need mbstring extension which are unicode enabled. Why should one rape a non unicode systems by having to tamper with package.use because he needs mbstring functionality. Why should we punished? I'm not the one to blame that I should use a locale different from unicode. Why should I suffer because of it? And how many packages in the future I have to tweak package.use? No way. Every mbscript utilizing php script's ebuild should be force users to enable unicode for php on a per package base? This is just not what USE flags are all about. Package.use is for special cases not for this kind. This bug was unfortunatelly opened, because someone found it annoying that mbstring depends on "nls". I can tell you, that it's at least that annoying that it depends on "unicode". You'll have several others in the future worldwide sucking because of this concept. Do you like this idea? I don't think there were many of them suffering because of the previous concept. Regards, Dwokfur
(In reply to comment #10) > Forget it, it's not related to squirrelmail. > Unicode is not a php USE flag. It's a system-wide use flag Eh? So is nls... squirrelmail is missing bunch of USE flags checks, not only wrt mbstring, so file a bug about it. > It's a system-wide use flag, which indicates if it's a unicode enabled system or not. So is nls. We are not going to invent redundant use-flags for unicode-related functionality just b/c you dislike unicode and dislike package.keywords. USE="nls" pulls in gettext and bunch of other cruft not desired on uclibc/embedded etc. > Why should one rape a non unicode systems > by having to tamper with package.use because he needs mbstring functionality. Why should one rape non-nls system doing the same? Starts to be boring, really... Not going to flip the flags back and forth, live with it. Sorry if you dislike it, we can't accomodate everyone's personal personal preferences. Case closed. ;)
(In reply to comment #11) > (In reply to comment #10) > > It's a system-wide use flag, which indicates if it's a unicode enabled system or not. > > So is nls. We are not going to invent redundant use-flags for unicode-related > functionality just b/c you dislike unicode and dislike package.keywords. > USE="nls" pulls in gettext and bunch of other cruft not desired on > uclibc/embedded etc. Unicod also pulls in a bunch of cruft nondesired on non-unicode systems. uclicbc/embedded users could also add "nls" to their package.use. > > Why should one rape a non unicode systems > > by having to tamper with package.use because he needs mbstring functionality. > > Why should one rape non-nls system doing the same? Starts to be boring, > really... Not going to flip the flags back and forth, live with it. Sorry if > you dislike it, we can't accomodate everyone's personal personal preferences. This is just not about me. > Case closed. ;) Ridiculous (I've managed find a world, which won't be moderated). What sould I expect in the future? Thanks for the appreciation in the name of all users being in the same situation as me. Don't search for a smiley in my case... Regards, Dwokfur
nls/unicode as proposed in comment #2 is logical and correct mbstring() is a function used for *unicode* and nothing else we have /etc/portage/package.use if you only want to enable unicode for php
(In reply to comment #13) > nls/unicode as proposed in comment #2 is logical and correct > > mbstring() is a function used for *unicode* and nothing else > > we have /etc/portage/package.use if you only want to enable unicode for php Nope. mbstring() function is used on _every_ machine running a php script, which calls it. Not just the ones, which have "unicode" USE flag enabled. Please have a look at on "Supported Character Encodings" at "http://www.php.net/mbstring". I do not want to enable unicode for php. It seems, that I have to open my local eclass repository. I'm totally dissapointed wasting my time here. Regards, Dwokfur
(In reply to comment #14) > Nope. > mbstring() function is used on _every_ machine running a php script, which > calls it. Eh? Gasoline is used in every car unless it's a diesel? :P > I do not want to enable unicode for php. So don't, we don't want yet another use flag and it doesn't fit well under nls one. > I'm totally dissapointed wasting my time here. Same feeling here, so no need to feel bad about it. ;) Well, I'm closing this bug since it's been fixed; vapier - please don't forget to check horde ebuilds. Thanks. Everyone else, file a *separate* bug for webapps that don't check for needed PHP features.
