[packages/mysql] - don't mark db error messages files with lang as these depend on db client settings and not db serv

[Jeff Johnson]

On Jul 6, 2016, at 10:05 AM, Arkadiusz Miśkiewicz wrote:

> On Wednesday 06 of July 2016, Elan Ruusamäe wrote:
>> vote: no
>> 
>> %lang has always been used in system way you want locale/localization
>> stuff installed
> 
> mysql is kind of special that doesn't fit well into typical %lang rules.
> 
> mysql server settings are not the ones that decide which error messages to 
> use.
> 
> It's remote clients who decide on error messages. What's worse - if client 
> wants some "locale" it won't silently switch to english. It will return error 
> instead.
> 
> These missing files break phpmyadmin functionality for switching languages.
> 
> 15:54:48 mysql{2}> SET lc_messages = 'ru_RU';
> ERROR 1231 (42000): Variable 'lc_messages' can't be set to the value of 
> 'ru_RU'
> Warning (Code 1105): Can't process error message file for locale 'ru_RU'
> Error (Code 1231): Variable 'lc_messages' can't be set to the value of 'ru_RU'
> 
> 
> After my change:
> 15:56:08 mysql{1}> SET lc_messages = 'ru_RU';
> Query OK, 0 rows affected (0.01 sec)
> 

> 
> And another problem - there is no way in rpm to specify special settings (to 
> get all locale files installed if %lang is used) for single rpm package 
> (mysql).
> 

Yes. Installations become stateful and there is no simple way to map
the statefulness of not installed files into dependencies.

> It's global which sucks in this case because only mysql error message files 
> are needed and not whole /usr/share/locale/XYZ for every application.
> 
> So I think such compromise is ok for mysql.
> 

Splitting out %lang(XY) marked files into a lang marked package is often done
to permit installing/removing additional locales as needed.

There is also no rpm detection/enforcement of %lang(XY) marked files, including encoding.

73 de Jeff